التفكير في استخدام "POST فقط"؟ لننهي جدل تصميم واجهة برمجة التطبيقات السخيف

مؤخراً، لفتت انتباهي مناقشة حول ما إذا كان ينبغي تصميم واجهات برمجة التطبيقات باستخدام "POST فقط". بعدما تعمقت في هذا الجدل، وجدت أن المشكلة ليست فقط تافهة ولا معنى للنقاش حولها، بل تكشف أيضاً عن سوء فهم العديد من المطورين لجوهرة تصميم واجهات برمجة التطبيقات. اليوم، دعونا نغوص عميقاً في الأفكار الأساسية لتصميم واجهات برمجة التطبيقات ونرى لماذا يجب ألا يكون هذا الجدل موجودًا من الأساس.

سوء فهم "POST فقط"#

المطورون الذين يدعون لاستخدام "POST فقط" لاستبدال مواصفات واجهة برمجة التطبيقات RESTful لم يفهموا بوضوح أهم نقطة في تصميم واجهات برمجة التطبيقات. تتضمن حججهم عادةً:

1. تبسيط التصميم: يمكن لطريقة واحدة التعامل مع كل شيء
2. الأمان: عناصر POST لا تظهر في عنوان URL
3. المرونة: POST يمكن أن يرسل أي هيكل بيانات

في النظرة الأولى، تبدو هذه الحجج منطقية بعض الشيء. لكن في الواقع، هذا الرأي يخلط بين اختيار طرق HTTP مع أساليب تصميم واجهات برمجة التطبيقات، وهما مستويان مختلفان من القضايا. POST هو مجرد طريقة واحدة من بروتوكول HTTP، بينما REST هو أسلوب لتصميم واجهات برمجة التطبيقات.

جوهر تصميم واجهات برمجة التطبيقات#

قبل مناقشة أساليب واجهات برمجة التطبيقات المحددة، نحتاج إلى فهم ما هو الغرض الأساسي من تصميم واجهات برمجة التطبيقات. يجب أن تكون واجهة برمجة التطبيقات الجيدة:

1. واضحة ومفهومة: يجب أن يتمكن المطورون الآخرون (بما في ذلك ذاتك المستقبلية) من فهم الغرض من كل نقطة نهاية بشكل بديهي
2. متناسقة: اتباع مواصفات معينة لتقليل تكاليف التعلم
3. قابلة للتوسع: القدرة على إجراء التحكم في الإصدار والتوسع الوظيفي بسهولة
4. فعالة: مراعاة الكفاءة من حيث الأداء واستخدام الموارد

واجهة برمجة التطبيقات RESTful: أكثر من مجرد اختيار لطرق HTTP#

واجهة برمجة التطبيقات RESTful هي واحدة فقط من العديد من أساليب تصميم واجهات برمجة التطبيقات، تركز على الموارد والعمليات على الموارد. لنأخذ نظام مدونات بسيط كمثال لنرى كيف يتم تصميم واجهة برمجة التطبيقات RESTful:

1. الحصول على جميع المقالات:

2. الحصول على مقالة معينة:

3. إنشاء مقالة جديدة:

4. تحديث مقالة:

5. حذف مقالة:

في هذا المثال، يمكننا أن نرى:

• تم تصميم واجهة برمجة التطبيقات حول المورد "article"
• تم استخدام طرق HTTP المختلفة لتمثيل العمليات المختلفة
• بنية عنوان URL واضحة، مما يشير إلى المورد الذي يتم تشغيله

يجعل هذا النهج في التصميم واجهة برمجة التطبيقات أكثر بديهية وشرحًا ذاتيًا، مما يسهل على المطورين فهم وظيفة كل نقطة نهاية.

RPC: فهم أسلوب واجهة برمجة التطبيقات وراء "POST فقط"#

الهدف من تصميم واجهة برمجة التطبيقات بأسلوب RPC (استدعاء الإجراء البعيد) هو جعل استدعاءات الخدمة البعيدة تبدو بسيطة مثل استدعاء الوظائف المحلية.

من المثير للاهتمام، أن أولئك الذين يدعون لـ "POST فقط" قد لا يدركون أنهم في الواقع يصفون أسلوب RPC.

مقارنة بواجهات برمجة التطبيقات RESTful، يركز RPC أكثر على العملية نفسها بدلاً من المورد. لهذا السبب، عادةً ما تستخدم واجهات برمجة التطبيقات بأسلوب RPC شكل "فعل + اسم"، مثل getProduct(productId) أو createUser(userData).

في العديد من تطبيقات RPC، عادةً ما يتم إرسال جميع العمليات عبر طلبات POST إلى نفس نقطة النهاية، مع تحديد العملية المحددة والمعلمات في نص الطلب. هذا هو سبب أن فكرة "POST فقط" هي في الواقع أقرب إلى RPC من REST.

على سبيل المثال، يمكن أن يبدو طلب "تحصل على المنتج" بأسلوب RPC القائم على HTTP هكذا:

تقدم أطر عمل RPC الحديثة، مثل gRPC، تطبيقات أكثر قوة وكفاءة. دعونا نستخدم هذا المثال لنعرض أسلوب RPC:

أولاً، نقوم بتعريف الخدمة وصيغة الرسائل (باستخدام Buffer Protocols):

ثم، استخدام هذه الخدمة في عميل Node.js يكون بسيطًا مثل استدعاء وظيفة محلية:

في هذا المثال بأسلوب RPC، يمكننا أن نرى:

1. تحدد تعريف الخدمة بوضوح جميع العمليات المتاحة (في هذا المثال المبسط، GetArticle وCreateArticle).
2. لكل عملية أنواع طلب واستجابة محددة بوضوح.
3. تبدو شفرة العميل مثل استدعاء وظيفة غير متزامنة محلية، باستخدام await للانتظار للحصول على النتيجة، مما يخفي تعقيد الاتصال الشبكي بشكل أكبر.
4. لا توجد حاجة لإنشاء طلبات HTTP يدويًا أو تحليل استجابات JSON.

على الرغم من أن الطبقة الأساسية قد تستخدم fortfarande HTTP/2 كبروتوكول النقل، إلا أن أطر عمل RPC (مثل gRPC) تقدم للمطورين طبقة تجريد تجعل الاستدعاءات البعيدة تبدو وتشعر كاتصالات وظيفية محلية.

لذلك، يمكننا أن نرى أن معظم النقاشات حول "POST فقط" وواجهات برمجة التطبيقات RESTful يجب أن تكون في الأساس مناقشات حول هذين الأسلوبين لتصميم واجهات برمجة التطبيقات: REST وRPC. ولكن الأهم هو الاعتراف بأن هذين الأسلوبين كل منهما له سيناريوهاته المطبقة، ويجب أن يكون الاختيار مستندًا إلى الاحتياجات المحددة للمشروع، وليس التفضيل الشخصي.

REST مقابل RPC: لا تفوق مطلق أو نقص#

الآن بعد أن فهمنا الاختلافات بين REST وRPC، دعونا نلقي نظرة على سيناريوهات تطبيقها:

1. REST مناسب لـ:
   • التطبيقات الموجهة للموارد (مثل نظم إدارة المحتوى، منصات المدونات، مواقع التجارة الإلكترونية)
   • السيناريوهات التي تتطلب دعمًا جيدًا للتخزين المؤقت (طلبات GET قابلة للتخزين المؤقت بشكل طبيعي)
   • المشاريع التي تريد الاستفادة من السيمانتية HTTP (مثل استخدام الرموز الحالة المناسبة)
   • واجهات برمجة التطبيقات العامة التي تتطلب اكتشافًا جيدًا ووصف ذاتي
2. RPC مناسب لـ:
   • التطبيقات الموجهة للعملية (مثل العمليات المعقدة لمعالجة البيانات، التحكم في سير العمل)
   • الأنظمة التي تتطلب أداءً عاليًا وزمن انتقائي منخفضًا (مثل أنظمة التداول في الوقت الحقيقي)
   • الاتصالات بين الخدمات الدقيقة الداخلية (والتي قد تتطلب تمرير معلمات أكثر مرونة)
   • عندما لا يمكن ببساطة تعيين العمليات إلى عمليات CRUD (إنشاء، قراءة، تحديث، حذف)

يجب أن يكون اختيار الأسلوب مبنيًا على الاحتياجات الخاصة بك. في بعض الحالات، قد تستخدم حتى مزيجًا من هذين الأسلوبين داخل نفس النظام لتلبية احتياجات الأجزاء المختلفة.

الخاتمة#

1. جوهر تصميم واجهات برمجة التطبيقات يكمن في الوضوح، التناسق، القابلية للتوسع، والكفاءة، وليس في التقيد بطريقة أو أسلوب معين.
2. كل من RESTful وRPC هما نماذج تصميم واجهات برمجة التطبيقات الناضجة. يجب أن يكون الاختيار بينهما مستندًا إلى متطلبات المشروع، وليس التفضيل الشخصي.
3. إذا قررت استخدام "POST فقط"، فرجاءً قم بتصميم واجهة برمجة التطبيقات الخاصة بك وفقًا لأسلوب RPC. مثلها مثل RESTful، إنها مواصفات شائعة الاستخدام في الصناعة، ولكن يجب استخدامها في السيناريوهات المناسبة.
4. لا تدع نفسك تكون مرتبكًا بالتفاصيل التقنية السطحية. ما يهم حقًا هو ما إذا كانت واجهة برمجة التطبيقات الخاصة بك يمكن أن تخدم المستخدمين واحتياجات الأعمال بفعالية.
5. عندما تقوم بتصميم واجهات برمجة التطبيقات، خصص المزيد من الوقت للتفكير في نموذج الموارد الخاص بك، منطق الأعمال، واحتياجات المستخدمين، بدلاً من الانغماس في أي طريقة HTTP يجب استخدامها.

لنحول انتباهنا بعيدًا عن هذه الحجج التي لا معنى لها ونركز على تصميم واجهات برمجة التطبيقات الممتازة حقًا. بعد كل شيء، التكنولوجيا تهدف إلى حل المشكلات، وليس خلقها.