كُتب بواسطة Ludovico Fischer
HTTP هو اختصار لـ Hypertext Transfer Protocolويعني بروتوكول نقل النص التشعبي، وهو حياة الويب وأساسه. يتم استخدامه في كل مرة تقوم فيها بنقل مستند، أو تقوم بطلب AJAX. ولكن من المدهش أن بروتوكول HTTP غير معروف نسبياً بين بعض مطوري الويب.
سوف توضح هذه المقدمة كيف أن مجموعة مبادئ التصميم، المعروفة باسم REST، تدعم بروتوكول HTTP، وتسمح لك باستخدام كامل قوتها من خلال بناء واجهات، والتي يمكن استخدامها من أي جهاز أو نظام تشغيل تقريباً.
يحتوي سوق Envato أيضاً على الآلاف من النصوص البرمجية المفيدة والملحقات والتطبيقات لمساعدتك على تطوير الويب، مثل HTTP Assistant، وهو تطبيق يساعدك على اختبار خدمات الويب على الإنترنت.
إعادة نشر المقال
كل بضعة أسابيع، نعيد النظر في بعض المقالات المفضلة لقرائنا عن طريق تاريخ الموقع. تم نشر هذا المقال للمرة الأولى في نوفمبر 2010.
لماذا REST؟
إن REST هي طريقة بسيطة لتنظيم التعاملات بين الأنظمة المختلفة والمستقلة.
إن REST طريقة بسيطة لتنظيم التفاعلات بين الأنظمة المستقلة. لقد زادت شعبيتها منذ عام 2005، وتساعد في تصميم الخدمات، مثل Twitter API. ويرجع ذلك إلى حقيقة أن REST تسمح لك بالتفاعل مع الحد الأدنى من التكاليف الإضافية مع العملاء مثل الهواتف المحمولة والمواقع الأخرى. نظرياً، فإن REST ليست مربوطة بالويب، لكنها تقريباً طُورت على هذا الأساس، وقد استُوحيت من بروتوكول HTTP. ونتيجة لذلك، فإنه يمكن استخدام REST حيثما كان استخدام HTTP ممكناً.
والبديل هو بناء اتفاقيات معقدة نسبيا فوق بروتوكول HTTP. وغالباً ما يأخذ هذا شكل لغات جديدة قائمة على XML بأكملها (XML-based). المثال الأكثر روعة هو SOAP. يجب أن تتعلم مجموعة جديدة تماماً من الاتفاقيات، لكنك لا تستخدم بروتوكول HTTP في كامل إمكانياتها. ولأن REST قد استُلهمت من بروتوكول HTTP وتعرف مدى قوته وتلعب على ذلك، فإنه أفضل طريقة لتعلم كيفية عمل بروتوكول HTTP.
بعد نظرة عامة أولية، سوف نقوم بفحص كل من لبنة (block) من لبنات بناء HTTP: عناوين الربط URL وأفعال HTTP (HTTP verbs) وأكواد الاستجابة. وسوف نستعرض أيضاً كيفية استخدامها بطريقة RESTful. وبعد ذلك، سنوضح النظرية عن طريق تطبيق مثال، والذي يحاكي عملية تتبع البيانات المتعلقة بعملاء الشركة من خلال واجهة الويب.
HTTP
HTTP هو البروتوكول الذي يسمح بإرسال المستندات ذهاباً وإياباً على الويب.
HTTP هو البروتوكول الذي يسمح بإرسال المستندات ذهاباً وإياباً على الويب. البروتوكول هو مجموعة من القواعد التي تحدد أي الرسائل يمكن تبادلها، وأي الرسائل هي الردود المناسبة على الآخرين. وهناك بروتوكول آخر مشترك وهو POP3، والذي قد تستخدمه لجلب البريد الإلكتروني على قرصك الصلب.
في HTTP، هناك دوران مختلفان: الخادم والعميل. وبشكل عام، العميل يبدأ الحوار دائماً؛ والخادم يقوم بالرد. بروتوكول HTTP مبني على النص؛ أي أن الرسائل هي عبارة عن أجزاء من النص، على الرغم من أن الرسالة يمكن أن تحتوي أيضاً على وسائط أخرى. استخدام النص يجعل من السهل مراقبة تبادل الـHTTP.
رسائل HTTP مُكونة من رأس (header) و جسم (body). ويمكن أن يبقى الجسم (body) فارغاً؛ ويحتوي على البيانات التي تريد إرسالها عبر الشبكة، لتستخدمها وفقاً للتعليمات الواردة في الرأس (header). يحتوي الرأس (header) على بيانات أولية، مثل معلومات التشفير؛ ولكن في حالة الطلب، فإنه يتضمن أيضاً دوال هامة لبروتوكول HTTP. في نمط REST، سوف تجد أن بيانات الرأس (header) أكثر أهمية من الجسم (body).
التجسس على HTTP أثناء العمل
إذا كنت تستخدم لوحة تحكم المطور في Google Chrome أو قمت بتنزيل إضافة firebug في متصفح Firefox، اضغط على لوحة الشبكة (Net)، وعين القيمة إلى تمكين (enabled). سيكون لديك بعد ذلك القدرة على عرض تفاصيل طلبات بروتوكول HTTP أثناء التنقل. على سبيل المثال:
cURL عبارة عن أداة في سطر الأوامر (command line)، موجودة في جميع أنظمة التشغيل الرئيسية.
عندما تقوم بتحميل الأداة اكتب التالي:
هذا سيعرض كل مراسلات الـHTTP. الطلبات تكون مسبوقة ب علامة > ، بينما الاستجابة تكون مسبوقة بعلامة <.
URLs
URLs هي عبارة عن كيف تعرف الأشياء التي تريد أن تتعامل معها. نقول أن كل عنوان URL يحدد مصدر. هذه بالضبط نفس عناوين URLs التي تم تعيينها لصفحات الويب. في الواقع صفحة الويب هي نوع من المصادر. لنأخذ مثالاً أكثر غرابة، لنتأمل تطبيق لنا، يدير قائمة زبائن الشركة:
هذا سيحدد جميع الزبائن، في حين:
سيحدد الزبون بالاسم ‘jim’، على افتراض أنه الوحيد الذي لديه هذا الاسم.
في هذه الأمثلة، لا نقوم عموماً بتضمين اسم المضيف في عنوان URL، لأنه ليس له علاقة في كيفية تنظيم الواجهة. مع ذلك، فإن اسم المضيف مهم لضمان أن معرِّف المصدر فريد في كل أنحاء الويب. غالباً ما نقول أنك ترسل طلب المصدر إلى المضيف. يتم وضع المضيف في الرأس (header) بشكل منفصل عن مسار المصادر، والذي يأتي فوق رأس الطلب (request header) مباشرة:
من الأفضل أن ننظر إلى المصادر باعتبارها معلومات. على سبيل المثال، ما يلي ليس RESTful:
هذا لأنها تستخدم عنوان URL لوصف عمل ما (action). وهذه نقطة أساسية للتميز بين أنظمة RESTful والأنظمة الغير RESTful.
وأخيراً، لابد أن تكون عناوين URL على قدر من الدقة، كل ما يجب أن يكون معرف فريد للمصدر، يجب أن يكون في الـURL. لا يجب عليك تضمين بيانات تحدد المصدر في الطلب (request). لأنه بهذه الطريقة، تعمل عناوين URL كخريطة كاملة لكل البيانات التي تتعامل معها تطبيقاتك.
ولكن كيف تحدد عمل ما (action)؟ على سبيل المثال، كيف يمكنك القول أنك تريد إنشاء سجل عميل جديد بدلاً من استرجاع بيانات؟ هنا يأتي دور أفعال (HTTP (HTTP verbs.
أفعال HTTP (HTTP verbs)
كل طلب يحدد فعل حقيقي للـ(HTTP (HTTP verb أو دالة، في رأس (header) الطلب. وهي الكلمة الأولى بالأحرف الكبيرة في رأس الطب (header request). على سبيل المثال:
ويعني أنه تم استخدام دالة GET، بينما
يعني أنه تم استخدام دالة الـ DELETE.
تخبر أفعال (HTTP (HTTP verbs\ الخادم بما يجب فعله بالبيانات المعرّفة بواسطة عنوان URL.
تخبر أفعال (HTTP (HTTP verbs الخادم بما يجب فعله بالبيانات المعرّفة بواسطة عنوان URL. يمكن أن يحتوي الطلب اختيارياً على معلومات إضافية في جسمه (body)، والتي قد تكون مطلوبة لتنفيذ العملية – مثل البيانات التي تريد تخزينها مع المصدر. يمكنك تزويد هذه البيانات في cURL بخيار -d.
إذا قمت في أي وقت مضى بصنع نماذج forms) HTML)، ستكون على دراية باثنين من أهم الأفعال لـ HTTP: (احصل) GET و(أرسل) POST. لكن هناك الكثير من أفعال HTTP المتوفرة. وأهم تلك الأفعال تلك التي تساعد على بناء واجهة برمجة تطبيقات RestFull API هي (احصل) GET و(أرسل) POST و(ضع) PUT و(احذف) DELETE. تتوفر دوال أخرى، مثل (رأس) HEAD و (خيارات) OPTIONS، لكنها نادرة أكثر (إذا كنت تريد أن تعرف عن جميع طرق HTTP الأخرى، المصدر الرسمي هو IETF).
GET
GET هو أبسط نوع من دوال الطلب في HTTP؛ التي يتم استخدمها في المتصفحات في كل مرة تقوم فيها بنقر رابط أو بكتابة عنوان URLفي شريط العنوان في المتصفح. إنه يُرشد الخادم (server) إلى نقل البيانات المعرّفة بواسطة عنوان URL إلى العميل (client). لا يجب أبداً تعديل البيانات من جهة الخادم (server) عند القيام بعملية طلب GET. وبهذا المعنى، فإن طلب GET يكون للقراءة فقط، ولكن بطبيعة الحال، بمجرد تلقي العميل (client) للبيانات، فإنه حر في القيام بأي عملية من جهته – على سبيل المثال، تنسيقه للعرض.
PUT
يتم استخدام طلب PUT عندما ترغب في إنشاء أو تحديث المصدر المعرّف بواسطة عنوان URL. على سبيل المثال،
قد ينشئ عميل (client)، يسمى Robin على الخادم (server). ستلاحظ أن REST هي عملية لا إرادية في الخلفية (backend)؛ فلا يوجد في الطلب أي شيء يخبر الخادم عن كيفية إنشاء البيانات – فقط ما يجب عمله. يتيح لك هذا تبديل تقنيات الطرف الخلفي (backend) بسهولة إذا دعت الحاجة إلى ذلك. تحتوي طلبات PUT على البيانات التي ستستخدم في تحديث أو انشاء المصدر في الجسم (body). في عنوان URL، يمكنك إضافة بيانات إلى الطلب باستخدام المحول -d.
DELETE
يعمل DELETE عكس أداء الـPUT، ويجب استخدامه عند عندما تريد حذف المصدر المعرّف بواسطة عنوان URL الخاص بالطلب.
سوف يحذف هذا جميع البيانات المرتبطة بهذا المصدر، والتي تم تحديدها بواسطة /clients/anne.
POST
يتم استخدام POST عند تكرار المعالجة التي ترغب في حدوثها على الخادم (server)، إذا تم تكرار طلب POST (بمعنى أنها ليست فعالة؛ المزيد على ذلك النحو أدناه). بالإضافة إلى ذلك، طلبات POST يجب أن تتسبب في معالجة الطلب في الجسم (body) كجهة تابعة لـ URL الذي تقوم بالنشر عليه.
بكلمات واضحة:
لا يجب أن يؤدي إلى تعديل المصدر في /clients/ itself، بل إلى تغيير المصدر الذي عنوان URL له يبدأ بـ /clients/. على سبيل المثال، يمكن أن تتم إضاافة عميل (client) جديد إلى القائمة، مع المعرّف (id) الموَلّد من الخادم (server).
يتم استخدام طلبات PUT بسهولة مقارنة بطلبات POST، والعكس صحيح. بعض الأنظمة تستخدم واحداً فقط من الدوال، وبعض منها يستخدم POST لإنشاء عمليات جديدة، و PUT لعمليات التحديث (بما أنه مع طلب PUT تقوم دائماً بتزويد عنوان URL الكامل)، و بعضها يستخدم POST للتحديثات وPUT للإنشاء.
غالباً ما تُستخدم طلبات POST لتشغيل العمليات على الخادم (server)، والتي لا تتناسب مع نموذج CREATE/UPDATE/DELETE؛ ولكن هذا يتجاوز نطاق REST. في مثالنا، سوف نتمسك بـ PUT دائماً.
تصنيف دوال HTTP
الدوال الآمنة وغير الآمنة:
الدوال الآمنة هي تلك التي لا تغير المصادر أبداً. الدوال الآمنة الوحيدة، من الدوال الأربعة المذكورة أعلاه، هي GET. أما الدوال الأخرى فهي غير آمنة، لأنها قد تؤدي إلى تعديل على المصادر.
الدوال الغير فعالة:
تحقق هذه الدوال النتيجة ذاتها مهما تكرر الطلب، وهذه الدوال هي GET، PUT، DELETE. الدالة الوحيدة الفعالة هي POST. دالة PUT و DELETE هي دوال غير فعالة، قد يكون ذلك غريباً بالنسبة لك. رغم ذلك، من السهل تفسير ذلك: تكرار دالة PUT بنفس الجسم (body) بالضبط ينبغي أن يعدل المصدر بطريقة تجعله مطابقاً لطلب PUT السابق: لن يتغير شيء! وبالمثل، ليس من المنطقي حذف مصدر مرتين. ويترتب على ذلك أنه بغض النظر عن عدد المرات التي يتكرر فيها طلب PUT أو DELETE، ينبغي أن تكون النتيجة هي نفسها كما لو كانت قد تمت لمرة واحدة فقط.
تذكر: أنت، المبرمج، الذي تقرر ما الذي يحدث عند استخدام دالة HTTP معينة. لا يوجد شيء متأصل في تكوين HTTP سيتسبب تلقائياً في إنشاء المصادر أو سردها كقائمة أو حذفها أو تحديثها. يجب أن تكون حريصاً على تطبيق بروتوكول HTTP بشكل صحيح وتطبيق هذه الكلمات الدلالية بنفسك.
التمثيل
يقوم عميل client) HTTP) وخادم server) HTTP ) بتبادل المعلومات حول المصادر التي تم تحديدها بواسطة عناوين URL.
يمكننا تلخيص ما تعلمناه حتى الآن بالطريقة التالية: عميل client) HTTP) و خادم (server HTTP) يتبادلان المعلومات حول المصادر المعرّفة من قبل عناوين URL.
ونقول إن الطلب (request) والرد (response) يتضمنان تمثيلاً للموارد. و نعني بالتمثيل، المعلومات في شكل معين، ونعني حالة المصدر أو عن كيف ستكون الحالة في المستقبل. كل من الرأس (head) والجسم (body) أجزاء من التمثيل.
ترويسات (headers HTTP)، التي تحتوي على بيانات أولية، يتم تعريفها بإحكام بواسطة مواصفات HTTP؛ يمكن أن تحتوي فقط على نص عادي، ويجب أن تكون منسقة بطريقة معينة.
يمكن أن يحتوي الجسم (body) على بيانات بأي شكل، وهنا تتألق قوة HTTP حقاً. أنت تعلم أنه يمكنك إرسال نص عادي، صور، HTML، و XML بأي لغة بشرية. من خلال البيانات الأولية للطلب أو عناوين URL المختلفة، ويمكنك الاختيار بين تمثيلات مختلفة لنفس المصدر. على سبيل المثال، قد ترسل صفحة ويب إلى المتصفحات وJSON إلى التطبيقات.
يجب أن تحدد استجابة (response HTTP ) نوع المحتوى الخاص بالجسم (body). يتم ذلك في الرأس (head)، في حقل نوع المحتوى (Content-Type)؛ على سبيل المثال:
وببساطة، في المثال يرسل التطبيق JSON ذهابا وإيابا فقط، ولكن يجب أن يكون التطبيق مصمم بطريقة يمكنك من خلالها تغيير تنسيق البيانات بسهولة، بحيث يتم تكييفها لعملاء (clients) مختلفين أو حسب تفضيلات المستخدم المختلفة.
مكتبات عميل (client HTTP)
cURL في معظم الأحيان، هو حل عميل (client HTTP) المفضل لمطوري PHP.
للتجريب مع دوال الطلب المختلفة، تحتاج إلى عميل (client)، والذي يتيح لك تحديد الدالة التي تريد استخدامها. لسوء الحظ، لا تتناسب نماذج (forms HTML) مع الفاتورة، لأنها تسمح لك فقط بإعداد طلبات GET و POST. في الواقع، يمكن الوصول إلى APIs برمجياً من خلال تطبيق عميل (client) منفصل، أو من خلال JavaScript في المتصفح.
وهذا هو السبب في أنه، بالإضافة إلى الخادم (client)، من الضروري توفر إمكانيات عميل (client) HTTP جيدة باللغة التي تختارها للبرمجة.
مكتبة عميل (client HTTP) شائعة جداً هي cURL. لقد تم اطلاعك مسبقاً على أمر cURL في بداية هذا المقال. يتضمن cURL كلاً من برنامج سطر أوامر مستقل ومكتبة يمكن استخدامها من خلال لغات برمجة مختلفة. وبشكل خاص، cURL هو الحل المفضل لدى مطوري PHP أكثر من أي وقت مضى. لغات أخرى، مثل بايثون، تقدم المزيد من مكتبات عميل (client HTTP) الأصلية.
اعداد مثال التطبيق
أريد أن أفضح وظائف المستوى المنخفض قدر الإمكان.
مثالنا في تطبيق PHP هو مكشوف للغاية. أريد أن أفضح وظائف المستوى المنخفض قدر الإمكان، بدون أي إطار عمل (framework) سحري. كما أنني لا أريد استخدام واجهة برمجة التطبيقات (API) الحقيقية، مثل Twitter، لأنها عرضة للتغيير بشكل غير متوقع، وتحتاج إلى إعداد مصادقة، وهو ما قد يشكل مشكلة، ولن تستطيع دراسة التطبيق بوضوح.
لتشغيل تطبيق الأمثلة، ستحتاج إلى تثبيت PHP5 وخادم ويب (web server)، مع بعض الآليات لتشغيل PHP. يجب أن يكون الإصدار الحالي على الأقل اصدار 5.2 لتتمكن من الوصول إلى دالتي ()json_encode و ()json_decode .
أما بالنسبة للخوادم (servers)، فإن الخيار الأكثر شيوعاً لا يزال يتمثل في استخدام الـ Apache مع mod_php، ولكن لك الحرية باستخدام أي بدائل تكون مرتاحاً معها. يوجد نموذج من إعداد Apache، يحتوي علي قواعد إعادة الكتابة لمساعدتك في إعداد التطبيق بسرعة. جميع الطلبات لأي عنوان URL، والتي تبدأ بـ /clients/ يجب توجيهها لملف server.php.
في نظام Apache، تحتاج إلى تمكين mod_rewrite ووضع التهيئة المضافة لـ mod_rewrite في مكان ما في تهيئة Apache الخاصة بك، أو ملف .htacess الخاص بك. بهذه الطريقة، سيستجيب ملف server.php لكل الطلبات الواردة من الخادم (server). يجب تحقيق نفس الشيء مع Nginx، أو أي خادم بديل تقرر استخدامه.
كيف يعمل مثال التطبيقات
هناك مفتاحان لمعالجة طلبات REST. المفتاح الأول هو بدء معالجة مختلفة، بناءً على دالة HTTP – حتى عندما تكون عناوين الـ URL متماثلة. في PHP، يوجد متغير في المصفوفة العامة $_SERVER، والذي يحدد الدالة التي تم استخدامها لتقديم الطلب:
المتغير يحتوي على اسم الدالة كنص، على سبيل المثال: ‘GET’,’PUT’، إلخ.
المفتاح الثاني هو معرفة أي عنوان URL تم طلبه. لفعل ذلك نستخدم متغير قياسي آخر من PHP:
يحتوي هذا المتغير عنوان URL الذي يبدأ بشرطة للأمام. على سبيل المثال، إذا كان اسم المضيف (host) هو ‘example.com’, ‘http://example.com/’، سوف يرجع ‘/’ بينما إذا كان ‘http://example.com/test/’ فسيرجع ‘/test/’.
دعونا أولاً نحاول تحديد عنوان URL الذي تم تسميته. سنهتم فقط في عناوين URL التي تبدأ بـ “clients”. كل ما عدا ذلك غير مسموح.
لدينا نتيجتان محتملتان:
- المصدر هو العملاء (clients)، في هذه الحالة، سنعيد قائمة كاملة
- هناك معرف إضافي
إذا كان هناك معرف آخر، نفترض أنه اسم العميل (client)، وقمنا بإرجاعه مرة أخرى إلى دالة مختلفة، بالاعتماد على الـmethod. نحن نستخدم عبارة التبديل(switch) التي يجب تجنبها في تطبيق حقيقي:
أكواد الاستجابة
أكواد الاستجابة في HTTP تقوم بتوحيد طريقة إعلام العميل (client) بنتائج طلبه.
قد تكون لاحظت أن تطبيق المثال يستخدم ترويسة الـ(()PHP header) لتمرير بعض النصوص (strings) الغريبة كمعطيات. تقوم دالة ()header بطباعة الـheaders HTTP وتتأكد من أنها منسقة بالشكل المناسب. يجب أن تكون الترويسات (headers) أول شيء في الاستجابة (response)، بحيث لا يجب عليك إخراج أي شيء آخر قبل أن تنتهي من الترويسات (headers). في بعض الأحيان، قد يتم إعداد الخادم (server HTTP) لإضافة ترويسات (headers) أخرى، بالإضافة إلى تلك التي تحددها في الكود الخاص بك.
تحتوي الترويسات (headers) على كل أنواع المعلومات الوصفية؛ على سبيل المثال، تشفير النص المستخدم في نص الرسالة في الجسم (body) أو نوع MIME من محتوى الجسم (body). في هذه الحالة، نقوم بتحديد أكواد استجابة HTTP بشكل صريح. وتعمل أكواد استجابة HTTP على توحيد طريقة إعلام العميل بنتائج طلبه. بشكل افتراضي، PHP تُرجع كود استجابة 200، مما يعني أن الاستجابة ناجحة.
يجب أن يقوم الخادم (server) بإرجاع كود استجابة HTTP الأنسب؛ وبهذه الطريقة، يمكن للعميل (client) محاولة إصلاح أخطائه، على افتراض وجود أي أخطاء. معظم الناس على دراية برمز الاستجابة 404 لا يمكن العثور على الصفحة، ولكن هناك الكثير من الأكواد متاحة لتلائم مجموعة متنوعة من المواقف.
تذكر أن معنى كود استجابة HTTP غير دقيق للغاية؛ وهذا نتيجة لكون بروتوكول HTTP نفسه عام. يجب عليك محاولة استخدام كود الاستجابة الذي يتطابق بشكل وثيق مع الوضع الموجود لديك. ومع ذلك، لا تقلق كثيراً إذا لم تجد أكواد ملائمة ودقيقة.
فيما يلي بعض أكواد استجابة HTTP، والتي غالبا ما تستخدم مع REST:
200 OK
يشير كود الاستجابة هذا إلى أن الطلب كان ناجحاً.
201 Created (تم إنشاؤه)
يشير هذا إلى أن الطلب تم بنجاح، وتم إنشاء المصدر. يتم استخدامه لتأكيد نجاح طلبات PUT أو POST.
400 Bad Request (طلب سيء)
يحدث إذا كان الطلب مشوهاً. ويحدث بشكل خاص مع طلبات PUT و POST عندما لا تتجاوز البيانات أكواد التحقق من الصحة، أو أن تكون بتنسيق خاطئ.
404 Not Found (غير موجود)
تشير هذه الاستجابة إلى أنه تعذر العثور على المصدر المطلوب. ويتم إرجاع هذا بشكل عام إلى جميع الطلبات التي تشير إلى عنوان URL بدون مصدر مقابل.
401 Unauthorized (غير مصرح به)
يشير هذا الخطأ إلى أنك بحاجة إلى إجراء مصادقة، قبل الوصول إلى المصدر.
405 Method Not Allowed (الدالة غير مسموح فيها)
دالة HTTP المستخدمة غير مدعومة لهذا المصدر.
409 Conflict (تعارض)
يشير هذا إلى تعارض. على سبيل المثال، أنت تستخدم طلب PUT لإنشاء نفس المصدر مرتين.
500 Internal Server Error (خطأ داخلي في الخادم)
وعندما يفشل كل شيء آخر؛ بشكل عام، يتم استخدام كود استجابة 500 عند فشل المعالجة بسبب ظروف غير متوقعة من جانب الخادم (server)، مما يؤدي إلى خطأ في الخادم (server).
ممارسة تطبيق المثال
لنبدأ ببساطة بجلب المعلومات من التطبيق. نريد تفاصيل العميل ‘client)، ‘jim)، لذا دعونا نرسل طلب GET بسيط للحصول على عنوان URL لهذا المصدر:
سيعرض هذا الرسائل الكاملة في الـ headers. والسطر الأخير في الرد هو جسم (body) الرسالة؛ في هذه الحالة، سيكون JSON يحتوي على عنوان jim (تذكر أن تجاهل اسم الدالة سيؤدي إلى طلب GET؛ أيضا استبدال localhost:80 باسم الخادم (server) والمنفَذ الذي تستخدمه).
وبعد ذلك، يمكننا الحصول على المعلومات لجميع الزبائن (clients) في وقت واحد:
لإنشاء زبون (client) جديد، باسم Paul..
وستحصل الآن على قائمة من جميع الزبائن (clients) الذين يحتوون على كلمة Paul كتأكيد.
أخيراً ، لحذف زبون (client):
ستجد أن JSON المُرجع لم يعد يحتوي علي أي بيانات عن Anne.
إذا حاولت استرجاع زبون (client) غير موجود، على سبيل المثال:
سوف تحصل على خطأ 404 بينما إذا حاولت إنشاء زبون (client) موجود مسبقاً:
سوف تحصل بدلاً من ذلك على خطأ 409.
الخاتمة
بشكل عام كلما كانت الافتراضات التي تقوم بها باتجاه HTTP أقل، كان ذلك أفضل.
من المهم أن نتذكر أن بروتوكول HTTP تم تصميمه للتواصل بين الأنظمة، التي لا تشترك إلا في فهم البروتوكول. بشكل عام، الافتراضات الأقل التي تقوم بها باتجاه HTTP، أفضل: يسمح ذلك لأوسع نطاق من البرامج والأجهزة بالوصول إلى واجهة برمجة التطبيقات (API) الخاصة بك.
لقد استخدمت PHP في هذا المقال، لأنه على الأرجح اللغة الأكثر شيوعاً لدى قراء Nettuts+. ورغم أن PHP مصممة للويب، فإنه من المحتمل أن لا تكون أفضل لغة يمكن استخدامها عند العمل بطريقة REST، حيث أنها تتعامل مع طلبات PUT بطريقة مختلفة تماماً عن GET و POST.
PHP من جانب آخر، يجب أن تهتم لما يلي:
- أطر (frameworks) Ruby المختلفة (Rails و Sinatra).
- هناك دعم REST ممتاز في Python.
- Node.js لديها دعم ممتاز لـREST.
من بين التطبيقات التي تحاول الالتزام بمبادئ REST، المثال الكلاسيكي هو بروتوكول النشر Atom Publishing Protocol، رغم أنه لا يستخدم في كثير من الأحيان في الممارسة العملية. لتطبيق حديث مبني علي فلسفه استخدام HTTP علي أكمل وجه، ارجع إلى Apache CouchDB.
ولا تنسَ التحقق من اختيار البرامج النصية للكود، الإضافات والتطبيقات في سوق Envato.
كن مستمتعاً!
