استخدام دوال HTTP لخدمات RESTful

REST اختصار لـ(REpresentational State Transfer)،  وتعني نقل الحالة المعروضة. و هو تصميم لتطوير خدمات الويب. إن الفائدة الرئيسية لاستخدام REST، من منظور العميل (client) والخادم (server)، هي أن التفاعلات القائمة على REST تحدث باستخدام قواعد مألوفة لكل من اعتاد على استخدام بروتوكول HTTP الخاص بالإنترنت.

بعد أن قلت ذلك، واحدة من أصعب المهام في REST هي إختيار الطرق الصحيحة. نحن جميعاً على دراية بالدوال الأساسية لـ HTTP مثل GET وPOST وPUT وDELETE. ولكن غالباً ما تحدث أخطاء عند تطبيقهم واستخدامهم.

قبل أن نغوص في أنواع  دوال الـ HTTP وحالات استخدامها، دعونا نلقي نظرة على كيفية تصنيفها.

تصنيف دوال HTTP

واستناداً إلى العملية التي تمت بواسطة دوال HTTP ، يمكن تصنيفها إلى فئتين —

دوال آمنة

هذه دوال HTTP التي لا تغير المصدر من جهة الخادم (server).

على سبيل المثال، استخدام طلب GET على عنوان URL للمصادر يجب أن لا يغير المصدر أبداً.

يمكن تخزين الدوال الآمنة مؤقتاً وإعادة إستعمالها بدون أي تأثير جانبي على المصدر.

GET /user/464

سيُرجع هذا, المستخدم 464. بغض النظر عن عدد المرات التي تقوم فيها بتنفيذ هذه الدالة، لن يتم تعديل أو التأثير على المصدر الموجود في الخادم (server).

دوال غير فعالة

هذه طرق آمنة من إتصالات متعددة، أي أنها تنتج نفس النتيجة بغض النظر عن عدد المرات التي تم استدعاؤها.

يقومون بتغيير المصدر في الخادم (server) في كل مرة يتم استدعاؤهم لكن النتيجة النهائية تكون دائماً واحدة.

مثال رياضي

a = 6; // غير فعال

a++; // فعال

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

كلما قمنا بإجراء تغييرات على المصفوفة باستخدام الفهارس (indexes)، فإنه سيكون دائماً غير فعال. بغض النظر عن عدد المرات التي قمت باستدعاء هذه العملية، فإن هذا سيؤدي دائماً إلى نفس السلوك، أي تعيين المصدر في موقع 464.

الآن بعد أن قمنا بتغطية الأساس الذي تم على أساسه تعريف دوال HTTP، دعونا نتعمق في مختلف أنواع دوال HTTP وحالات استخدامها.

أنواع دوال HTTP

(GET) جلب 

إرجاع المصدر من الخادم (server) (يجب أن يُرجع المصدر فقط ولا يجب أن يكون له تأثير آخر).

طلب GET هو آمن وغير فعال بنفس الوقت.

حالة استخدام – جلب مصدر أو مجموعة مصادر من الخادم (server).

أرسل (POST)

يستخدم نوع طلب HTTP هذا عادة لإنشاء كيان (entity)، أي مصدر بدون معرف (id). بمجرد إنشاء الطلب بنجاح، يتم إرجاع معرّف (id) المصدر الذي تم إنشاؤه حديثاً كجزء من الرد علي طلب HTTP.

على سبيل المثال، عنوان URL التالي سيقوم بإنشاء مستخدم جديد (user) في الخادم (server).

دالة POST ليست آمنة ولا غير فعالة.

دالة POST  ليست غير فعالة لأن استدعائها عدة مرات سينتج عنه انشاء مصدر جديد في كل مرة.

حالة استخدام – إنشاء مستخدم جديد على الخادم (server).

ضع (PUT)

شبيه لـ POST، ولكن يستخدم لتحديث مصدر موجود. يمكنك تمرير معرف المصدر الموجود مع الطلب.

على سبيل المثال، عنوان URL التالي سوف يستبدل المستخدم الذي لديه المعرف 464 في الخادم (server).

دالة PUT غير فعالة لأنها تسمح فقط بالاستبدال الكامل لمصدر ما.

وتنشئ مصدر جديد إذا لم يكن موجودا.

حالة استخدام — تحديث المصدر الكامل على الخادم (server).

تصحيح (PATCH)

تطبق دالة PATCH تعديلات جزئية على المصدر.

على عكس PUT، فإن PATCH ليست غير فعالة، مما يعني أن طلبات PATCH المتطابقة المتعاقبة قد يكون لها تأثيرات مختلفة.

ومع ذلك، من الممكن إصدار طلبات PATCH بطريقة تكون غير فعالة.

لمعرفة ما إذا كان الخادم (server) يدعم PATCH، هو وجود ترويسة (header) Accept-Patch في الاستجابة.

حالة استخدام — إذا كنت تريد تحديث حقل واحد فقط، أستخدم طلب PATCH.

حذف (DELETE)

يحذف المصدر من الخادم (server). يجب عليك تمرير معرف (id) المصدر ليتم حذفه.

على سبيل المثال، عنوان URL التالي سيقوم بإزالة المستخدم بمعرف 464.

حالة استخدام — حذف المصدر المحدد.

تعقب (TRACE)

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

حالة استخدام — هذه الطريقة ببساطة تُرجع للعميل (client) أي سلسلة نصية (string) تم إرسالها إلى الخادم (server)، وتستخدم أساساً لأغراض المعالجة (debugging).

رأس (HEAD)

دالة HEAD شبه متطابقة مع GET، باستثناء جسم (body) الاستجابة.

وبعبارة أخرى، إذا قام GET /users بإرجاع قائمة مستخدمين، سيقوم HEAD/users بنفس الطلب دون إرجاع  قائمة المستخدمين.

حالة استخدام — يستخدم غالباً من قبل العملاء (clients) الذين يستخدمون التخزين المؤقت. وبما أنه لا يحتوي على البيانات الفعلية، يمكن أن تساعدنا ترويسة الاستجابة من طلب HEAD على تحديد ما إذا كانت الوثيقة قد تغيرت منذ آخر وصول إليها.

خيارات (OPTIONS)

يسمح للعميل (client) بطلب معلومات حول دوال الطلب المدعومة من الخدمة.

حالة استخدام — يساعدنا على تحديد الدوال المدعومة في مصدر ما. ومن بين حالات الاستخدام الشائعة — التحقق مما إذا كان CORS مدعوماً من قبل الخادم (server) أم لا.

وصل (CONNECT)

يستخدم لبدء اتصالات ثنائية الاتجاه مع المصدر المطلوب.

حالة استخدام — يمكن استخدامه لفتح نفق عادة لتسهيل الاتصالات المشفرة (HTTPS) (SSL-encrypted communication) عبر وكيل بروتوكول HTTP الغير مشفر.

الطريقة	غير فعال	آمن
GET	نعم	نعم
POST	لا	لا
PUT	نعم	لا
DELETE	نعم	لا
PATCH	لا	لا
HEAD	نعم	نعم
OPTIONS	نعم	نعم

POST مقابل PUT مقابل PATCH

عندما بدأت العمل على REST، كانت إحدى أكبر الصعوبات التي واجهتها، متى أستخدم POST ومتى أستخدم PUT.

بطل القصة لهذه المعضلة هنا هو اللافعالية. يكون الطلب غير فعال إذا كانت الآثار الجانبية لجعل الطلب مرة واحدة مماثلة لمليون مرة. ولكن عندما يتعلق الأمر بسيناريوهات معينة  لـ post يمكن أن يكون لدينا طلب غير فعال طوال الوقت. (أي أنها لا تنشئ مصدراًجديدًا). وهذا هو السبب الذي يجعل من الممكن أيضا استخدام POST لتحديث المصدر.

وهذا يقودنا إلى السؤال –

POST مقابل PUT

من أجل تحديد ما إذا كنت تريد استخدام POST أو PUT، تذكر دائما قاعدتين —

1. لابد أن تكون نقطة النهاية غير فعالة: آمن أن نعيد الطلب مراراً وتكراراً.
2. يجب أن يكون URI عنوان المصدر الذي يجري تحديثه.على سبيل المثال

عند الاختيار بين PUT و POST، لا تقل فقط “PUT غير فعال”. وبدلاً من ذلك، أنظر إلى كل من القواعد أعلاه، وأنظر ما إذا كان يمكن أن يكون لدينا حالة لـ PUT. وإذا لم يستوف حتى قاعدة واحدة، فواصل باستخدام POST.

ويمكن أخذ مثال مبسط للعبارة المذكورة أعلاه من الارتباط إلى المصفوفة. إذا كنت تعتبر قاعدة البيانات db الخاصة بك مصفوفة، فإن POST يشبه القيام بعملية دفع (push)، بينما PUT يشبه تحديث المصدر في المصفوفة باستخدام الفهرس (index).

حالة للتصحيح(PATCH)

من الناحية التقنية، ينص تعريف  PUT على أن — “خذ هذا الكائن (object) واستبدل المصدر بأكمله في URI”.

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

في هذا السيناريو، يجب أن يقوم طلب PUT بتعيين البريد الإلكتروني على معرّف البريد الإلكتروني الجديد وتعيين الاسم لفارغ (null) بسبب عدم توفره في الطلب. لكن ليس كل الـ APIs تتبع هذه القاعدة لأنها قاسية نوعاً ما وستضع المحتوى فارغاً دون أن ينوي العميل (client) القيام بذلك.

وهنا يأتي سبب وجود PATCH ؛ لإنقاذ الوضع.

والسبب في أن الجميع ما زالوا يستخدمون طلب PUT للطلب المذكور أعلاه،  هو أن PATCH جديد نسبياً على عالم REST. (تم إدخال PUT في مستند RFC 2616 ، بينما تم إنشاء PATCH  في RFC 5789 ).

في العادة، تستخدم PATCH  تماماً مثل PUT، باستثناء إذا لم نرسل حقل اسم، فإنه يحتفظ بقيمته الحالية بدلاً من تغييرها إلى فارغة (null).

التعليقات الختامية

حالة استخدام دوال HTTP مختلفة. معرفة في الغالب عن طريق  الآمنة و غير الفعالة. إن REST هو ببساطة عقد بين العميل (client) والخادم (server)، مما يساعد على إنشاء بنية API قابلة للتطوير. يمكنك أيضاً استخدام طلب POST للحصول على قائمة من المصادر (على أي حال لا يجب عليك القيام بذلك) واستخدام GET لتحديث أو إنشاء مورد (مرة أخرى هذه فكرة سيئة)، حتى يتم كتابة الوقت الذي تسلم فيه API بهذه الطريقة.