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

على محمل الجد، إذا كنت تستخدم أبدا الباقون ولكن كنت قد للعمل مع (أو أسوأ من ذلك، خلق) في API SOAP، أو مجرد فتح WSDL ، وكان رأسك ينفجر، صبي لا بد لي من الأخبار الجيدة بالنسبة لك!

لذا، ما على الأرض هو الباقي؟ لماذا يجب أن يهمك؟

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

طلبات
جميع واجهات برمجة التطبيقات في حاجة لقبول طلبات. عادة، مع API مريح، سيكون لديك مخطط URL واضحة المعالم. دعونا نقول لكم نريد أن توفر API للمستخدمين على الموقع الخاص بك (وأنا أعلم، وأنا دائما استخدام "المستخدمين" مفهوم للحصول على أمثلة بلدي). كذلك، شكل الروابط ربما يكون شيء من هذا القبيل، "API / المستخدمين" و "API / المستخدمين / [ID]" اعتمادا على نوع العملية المطلوبة ضد API الخاص بك. تحتاج أيضا إلى النظر في كيفية كنت ترغب في قبول البيانات. في هذه الأيام الكثير من الناس يستخدمون JSON أو XML، وأنا شخصيا أفضل JSON لأنه يعمل بشكل جيد مع جافا سكريبت، PHP، ولها وظيفة من السهل على فك التشفير والترميز فيه. اذا كنت تريد API الخاص بك أن تكون قوية حقا، هل يمكن أن تقبل على حد سواء عن طريق استنشاق خارج محتوى من نوع من الطلب (أي تطبيق / JSON أو التطبيق / XML)، لكنه مقبول تماما لتقييد الأشياء إلى نوع محتوى واحد. هيك، حتى انك تستطيع استخدام بسيط أزواج مفتاح / قيمة إذا أردت.

قطعة أخرى من الطلب هو ما يعني في الواقع أن تفعله، مثل الحمل، وحفظ، وما إلى ذلك وبشكل طبيعي، وكنت قد لتأتي مع نوع من الهندسة المعمارية التي تحدد ما عمل الطالب (المستهلك) الرغبات، ولكن يبسط REST أن. باستخدام أساليب طلب HTTP، أو الأفعال، ونحن لسنا في حاجة لتحديد أي شيء. يمكننا فقط استخدام GET POST، طرح، وحذف الطرق، والتي تغطي كل طلب لكنا في حاجة. يمكنك أن تساوي بين الأفعال على الاشياء الخاصة بك الخام على غرار معيار: GET = تحميل / استرداد، وظيفة = خلق، طرح = التحديث، DELETE = جيد، وحذف. من المهم أن نلاحظ أن هذه الأفعال لا تترجم مباشرة إلى الخام، وإنما هو وسيلة جيدة للتفكير فيها. لذلك، يعود إلى أمثلة URL أعلاه، دعونا نلقي نظرة على بعض الطلبات ما ممكن يمكن أن يعني:

• طلب GET إلى / API / المستخدمين - قائمة جميع المستخدمين
• طلب GET إلى / api/users/1 - قائمة معلومات عن المستخدم مع رقم من 1
• طلب حضورك إلى / API / المستخدمين - إنشاء مستخدم جديد
• تأجيل طلب إلى / api/users/1 - تحديث المستخدم مع رقم من 1
• حذف طلب إلى / api/users/1 - حذف المستخدم مع رقم من 1

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

ردود
لذلك، REST معالجة طلبات بسهولة جدا، ولكنه أيضا يجعل من السهل توليد استجابات. مماثل للطلبات، وهناك عنصرين رئيسيين من استجابة مريح: الجسم ردا على ذلك، ورمز حالة. استجابة الجسم من السهل جدا للتعامل معها. مثل الطلبات، ومعظم الردود في باقي وعادة ما تكون إما JSON أو XML (ربما مجرد نص عادي في حالة وظيفة، ولكن سنقوم تغطية ذلك في وقت لاحق). و، مثل طلبات، يمكن للمستهلك تحديد نوع الرد الذي تريد من خلال جزء آخر من المواصفات طلب HTTP، "قبول". إذا كان المستهلك يرغب في الحصول على استجابة XML، ويهمني يرسلون مجرد قبول رأس كجزء من طلبها قائلا قدر ("قبول: التطبيق / xml"). وباعتراف الجميع، وليس هذا الأسلوب على نطاق واسع كما اعتمد (THO أنه ينبغي أن يكون)، حتى يكون لديك ويمكن أيضا استخدام مفهوم امتدادا في URL. على سبيل المثال، / API / users.xml يعني أن المستهلك يريد XML كرد فعل، وبالمثل / API / users.json يعني JSON (نفسه لأشياء مثل / api/users/1.json/xml). اما الطريقة التي تختارها (أقول به على حد سواء)، يجب عليك اختيار نوع الاستجابة الافتراضية كما الكثير من الوقت الناس متعود 'حتى ان اقول لكم ما يريدون. مرة أخرى، وأقول أن يذهب مع JSON. لذلك، لا اقبل رأس أو التمديد (أي / API / الأعضاء) يجب أن لا تفشل، يجب أن تفشل، ما يزيد قليلا على الافتراضي استجابة من نوع.

ولكن ماذا عن الأخطاء وغيرها من رسائل الحالة الهامة المرتبطة الطلبات؟ من السهل، واستخدام رموز الحالة HTTP! هذا هو الآن، وفوق واحدة من الأمور التي تعجبني في خلق مريح واجهات برمجة التطبيقات. من خلال استخدام رموز الحالة HTTP، لا تحتاج إلى الخروج مع خطأ / مخطط لنجاح API الخاص بك، لقد فعلت ذلك لك. على سبيل المثال، إذا كان المستهلك على الوظائف / API / المستخدمين وترغب في تقديم تقرير عن خلق الناجحة، ببساطة إرسال رمز حالة 201 (201 = الإنشاء). اذا فشلت، ارسال 500 اذا فشلت في نهاية الخاص بك (500 = خطأ خادم داخلي)، أو ربما 400 اذا كانوا ثمل (400 = طلب غير صالح). ربما انهم تحاول المشاركة ضد نقطة نهاية API التي لا تقبل المشاركات ... ارسال 501 (لم ينفذ). ربما لديك الخلية خادم باستمرار، بحيث يتم borked مؤقتا API الخاص بك ... ارسال 503 (الخدمة غير متوفرة). نأمل أن تحصل على هذه الفكرة. إذا كنت ترغب في قراءة قليلا عن رموز الحالة، التحقق منها في ويكيبيديا: قائمة من رموز حالة HTTP .

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

إذا كنت لا تزال غير مقتنعة بأن هذا هو نموذج API مفيدة، ونلقي نظرة على ما قامت به بقية لروبي على القضبان. واحد من مطالبها الرئيسية للشهرة هو كم هو سهل لخلق واجهات برمجة التطبيقات (من خلال نوع من الدجل والشعوذة ROR، وأنا متأكد)، وهي محقة في ذلك. منح أعرف القليل جدا عن ROR، ولكن فيلم Fanboys في جميع أنحاء المكتب قد بشر هذه النقطة لي مرات عديدة. ولكن، أنا استطرادا ... دعونا كتابة بعض رمز!

الشروع في العمل مع بقية وPHP

واحد إخلاء مشاركة: رمز نحن على وشك أن تتجاوز في أي وسيلة يعتزم استخدامها كمثال على حل قوي. هدفي الرئيسي هنا هو إظهار كيفية التعامل مع المكونات الفردية للراحة في PHP، وترك خلق الحل النهائي متروك لكم.

لذا، دعونا حفر في! وأعتقد أن أفضل طريقة للقيام بشيء عملي هو لإنشاء فئة من شأنها أن توفر جميع وظائف فائدة نحن بحاجة إلى إنشاء API REST. سنقوم أيضا إنشاء طبقة صغيرة لتخزين البيانات لدينا. هل يمكن أيضا، ثم يأخذون هذا، وتوسيعه، وتطبيقها على الاحتياجات الخاصة بك. لذا، دعونا كعب بعض الاشياء من:

 RestUtils فئة {العامة processRequest وظيفة ثابتة () {} جمهور sendResponse وظيفة ثابتة ($ = 200 حالة، $ الجسم =''، 'نص / HTML' $ content_type =) {} الجمهور ساكنة getStatusCodeMessage وظيفة ($ حالة) {/ / هذه ويمكن تخزينها في ملف. INI وتحميلها / / عبر parse_ini_file () ...  ومع ذلك، فإن هذا يكفي / / للحصول على مثال $ رموز = صفيف (100 => "متابعة"، 101 => 'تبديل البروتوكولات "، 200 =>' موافق '، 201 =>' إنشاء '، 202 =>' مقبول ' ، 203 => 'معلومات غير موثوقة "، 204 =>' لا المحتوى '، 205 =>' إعادة تعيين المحتوى '، 206 =>' محتوى جزئي '، 300 =>' خيارات متعددة '، 301 =>' انتقل للاقامة الدائمة" ، 302 => 'العثور على'، 303 => 'رؤية أخرى "، 304 =>' لم يتم تعديل '، 305 =>' وكيل الاستخدام '، 306 =>' (غير مستخدمة) '، 307 =>' إعادة توجيه مؤقتة"، 400 => 'طلب غير صحيح'، 401 => 'غير مصرح بها "، 402 =>' الدفع المطلوبة '، 403 =>' ممنوع '، 404 =>' لم يتم العثور على '، 405 =>' أسلوب غير مسموح '، 406 =>' غير مقبول '، 407 =>' وكيل المصادقة المطلوبة "، 408 => 'طلب مهلة'، 409 => '' 411، =>" الصراع "، 410 => 'ذهب الطول المطلوب'، 412 => 'فشل الشرط المسبق" ، 413 => 'كيان الطلب كبير جدا'، 414 => 'طلب-URI طويل جدا "، 415 =>' نوع الوسائط غير مدعوم '، 416 =>' مطلوب المدى satisfiable لا '، 417 =>' توقع فشل"، 500 => 'خطأ خادم داخلي "، 501 =>' لم ينفذ '، 502 =>' عبارة غير صالحة"، 503 => 'الخدمة غير متوفرة "، 504 =>' بوابة مهلة '، 505 =>' النسخة HTTP غير معتمد ') ؛ العودة (isset ($ رموز [$ الحالة]))؟  $ رموز [$ حالة]:''؛}} {RestRequest فئة خاصة $ request_vars؛ خاصة $ البيانات؛ خاصة $ http_accept؛ خاصة $ أسلوب؛ بناء العامة __ وظيفة () {دولار هذا-> request_vars = مجموعة ()؛ دولار هذا، > بيانات =''؛ دولار هذا-> http_accept = (قيمة تساوي ($ _SERVER ['HTTP_ACCEPT']، 'سلمان'))؟  "سلمان": "XML"؛ دولار هذا-> طريقة = 'حصول'؛} جمهور setData وظيفة ($ البيانات) {$ هذا-> بيانات = $ بيانات؛} setMethod وظيفة عامة ($ طريقة) {دولار هذا-> طريقة = $ أسلوب؛} setRequestVars وظيفة عامة ($ request_vars) {دولار هذا-> request_vars = $ request_vars؛} برنامج GetData ظيفة عمومية () {عودة دولار هذا-> البيانات؛} getMethod ظيفة عمومية () {عودة دولار هذا-> طريقة؛ } وظيفة عامة getHttpAccept () {عودة دولار هذا-> http_accept؛} getRequestVars ظيفة عمومية () {عودة دولار هذا-> request_vars؛}} 

حسنا، ماذا لدينا هي فئة بسيطة لتخزين بعض المعلومات عن طلب لدينا (RestRequest)، وفئة مع بعض وظائف ثابتة يمكننا استخدامها لمعالجة الطلبات والاستجابات. كما ترون، نحن حقا لا تملك إلا اثنين من وظائف الكتابة ... والذي هو جمال هذا الأمر برمته! الحق، دعنا ننتقل ...

معالجة الطلب

معالجة الطلب هي جميلة على التوالي إلى الأمام، ولكن هذا هو المكان الذي يمكن تشغيله في المصيد قليلة (مع أي طرح وحذف ... ضعي في الغالب). سنتقدم أكثر من تلك الموجودة في لحظة، ولكن دعونا النظر في فئة RestRequest قليلا. إذا كنت سوف ننظر في المنشئ، سترى أننا تفسير بالفعل رأس HTTP_ACCEPT، وتعثر على JSON إذا تم توفير لا شيء. مع أن للخروج من الطريق، ونحن بحاجة فقط التعامل مع البيانات الواردة.

وهناك عدد قليل من الطرق يمكننا أن نذهب عن القيام بذلك، ولكن دعونا نفترض فقط أن سنحصل دائما على زوج مفتاح / قيمة في طلبنا: 'البيانات' => ​​البيانات الفعلية. دعونا نفترض أيضا أن البيانات الفعلية ستكون JSON. كما جاء في تفسير رسالتي السابقة من الراحة، هل يمكن أن ننظر إلى نوع محتوى الطلب والتعامل مع أي من JSON أو XML، ولكن دعونا يبقيه بسيط في الوقت الراهن. لذلك، فإن لدينا وظيفة عملية طلب في نهاية المطاف يبحث شيئا من هذا القبيل:

 جمهور processRequest وظيفة ثابتة () {/ / الحصول على موقعنا الفعل $ request_method = strtolower ($ _SERVER ['REQUEST_METHOD'])؛ $ return_obj = جديد RestRequest ()؛ / / سوف نقوم بتخزين البيانات المتوفرة لدينا هنا مجموعة $ = البيانات ()؛ التبديل ($ request_method) {/ / يحصل من السهل ...  قضية 'الحصول على': $ البيانات = $ _GET؛ انقطاع / / هكذا هي الحال المشاركات 'آخر': $ البيانات = $ _POST؛ كسر؛ / / هنا هي صعبة بعض الشيء ...  'وضع' حالة: / / في الأساس، نقرأ سلسلة من موقع بي إتش بي للمساهمة خاصة، / / ومن ثم تحليل بها في صفيف عبر parse_str ...  لكل من مستندات PHP: / / شارع يوزع كما لو كانت سلسلة الاستعلام عن طريق تمرير URL ومجموعات / / المتغيرات في النطاق الحالي.  parse_str (file_get_contents ('بي :/ / الإدخال')، $ put_vars)؛ $ البيانات = $ put_vars؛ كسر؛} / ​​مخزن / الأسلوب $ return_obj-> setMethod ($ request_method) / / تعيين البيانات الخام، ولذا فإننا ويمكن الوصول إليه عند الحاجة (قد تكون هناك قطعة / / أخرى لطلباتك) $ return_obj-> setRequestVars ($ البيانات)، وإذا كان (isset ($ البيانات ['البيانات'])) {/ / ترجمة JSON إلى كائن لل ولكن تريد استخدام $ return_obj-> setData (json_decode ($ البيانات ['البيانات']))؛} العودة دولار return_obj؛} 

مثل قلت، جميل مستقيم الى الامام. ومع ذلك، عدد قليل من الأشياء أن نلاحظ ... أولا، عادة لا يقبل البيانات لطلبات DELETE، لذلك ليس لدينا قضية لهم في التبديل. الثانية، ستلاحظ أن نقوم بتخزين كل من متغيرات الطلب، وتحليل البيانات JSON. وهذا مفيد كما قد يكون لديك أشياء أخرى كجزء من طلبك (ويقول مفتاح API أو شيء ما) التي ليست حقا البيانات نفسها (مثل اسم المستخدم الجديد، والبريد الإلكتروني، وما إلى ذلك).

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

 $ البيانات = RestUtils :: processRequest ()؛

 التبديل ($ البيانات> getMethod)
 {
	 قضية 'الحصول على':
		 / / استرداد قائمة المستخدمين
		 كسر؛
	 قضية 'آخر':
		 $ المستخدم = العضو الجديد ()؛
		 $ للمستخدم> setFirstName ($ البيانات> برنامج GetData () - FIRST_NAME>) / / فقط على سبيل المثال، ينبغي أن يتم هذا النظيف
		 / / وهلم جرا ...
		 $ للمستخدم حفظ <()؛
		 كسر؛
	 / / الخ، الخ، الخ ...
 }

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

إرسال الاستجابة

الآن يمكننا أن نفسر هذا الطلب، دعنا ننتقل إلى إرسال الاستجابة. نحن نعلم بالفعل أن كل ما نحتاج إليه حقا القيام به هو إرسال رمز الحالة الصحيحة، وربما بعض الجسم (لو كان هذا طلب GET، على سبيل المثال)، ولكن هناك كمية الصيد المهم أن الردود التي ليس لها الجسم. ويقول شخص قدم طلبا ضد لدينا عينة API المستخدم للمستخدم الذي لا وجود لها (أي api/user/123). قانون الأحوال المناسبة لإرسال هو 404 في هذه الحالة، ولكن مجرد إرسال رمز الحالة في رؤوس ليست كافية. إذا قمت بعرضها تلك الصفحة في متصفح الويب الخاص بك، سوف تحصل على شاشة فارغة. وذلك لأن اباتشي (أو أيا كان خادم الويب الخاص بك يعمل على) لم يتم إرسال رمز الحالة، لذلك ليس هناك صفحة الحالة. سنحتاج إلى أخذ ذلك في الاعتبار عندما نبني وظيفة من أصل لدينا. حفظ كل ذلك في الاعتبار، وهنا ما رمز يجب أن تبدو:

	 جمهور sendResponse وظيفة ثابتة ($ = 200 حالة، $ الجسم =''، 'نص / HTML' $ content_type =) {$ status_header = 'HTTP/1.1 ".  $ الوضع.  ''.  RestUtils :: getStatusCodeMessage ($ حالة) / / تعيين وضع رأس ($ status_header) / / تعيين رأس نوع المحتوى ("محتوى من نوع: '. $ content_type) / / صفحات مع هيئة سهلة إذا دولار (هيئة ! ='') {/ / ترسل هيئة صدى $ الجسم؛ الخروج؛} / / نحن بحاجة إلى إنشاء هيئة إذا يتم تمرير أي شيء آخر {/ / خلق بعض الرسائل هيئة $ رسالة ='' / / هذا هو اختياري بحت ، ولكن يجعل من صفحات أجمل قليلا لقراءة / / للمستخدمين.  وبما انك لن ترسل على الأرجح الكثير من رموز الحالة مختلفة، / / هذا أيضا لا ينبغي أن يكون ثقيل جدا للحفاظ على التبديل ($ حالة) {القضية 401: $ رسالة = '. يجب أن يكون لديك الصلاحية لمشاهدة هذه الصفحة'؛ انقطاع، حالة 404: $ رسالة = 'URL المطلوب.  $ _SERVER ['REQUEST_URI'].  "لم يتم العثور على '؛ كسر؛ القضية 500: $ رسالة =' واجه ملقم خطأ في معالجة طلبك. '؛ كسر؛ القضية 501: $ رسالة ='. لم يتم تنفيذ هذه الطريقة المطلوبة '؛ كسر؛} / ​​/ ملقمات لم يكن لديك دائما توقيع تشغيل (وهذا هو التوجيه اباتشي "ServerSignature على") $ توقيع = ($ _SERVER ['SERVER_SIGNATURE'] =='')؟  $ _SERVER ['SERVER_SOFTWARE'].  "خادم في '.  $ _SERVER ['SERVER_NAME'].  'ميناء'.  $ _SERVER ['SERVER_PORT']: $ _SERVER ['SERVER_SIGNATURE']؛ / / يجب templatized هذا في التوصل إلى حل في العالم الحقيقي $ الجسم = '<DOCTYPE HTML PUBLIC "- / / W3C / / DTD HTML 4.01 / / EN! "" http://www.w3.org/TR/html4/strict.dtd "> <HTML> <HEAD> <التعريف HTTP-EQUIV =" نوع المحتوى "محتوى =" نص / HTML؛ محارف = ISO-8859 -1 "> <TITLE>".  $ الوضع.  ''.  RestUtils :: getStatusCodeMessage ($ الحالة).  </ عنوان> </ رئيس> <h1> تحليل <BODY> ".  RestUtils :: getStatusCodeMessage ($ الحالة).  "</ H1> <p> و".  $ رسالة.  "</ P> <hr /> <address>".  $ التوقيع.  </ عنوان> </ BODY> </ HTML> '؛ صدى $ الجسم؛ الخروج؛}} 

هذا كل شيء! لدينا من الناحية الفنية كل ما نحتاجه الآن لمعالجة طلبات وارسال الردود. دعونا نتحدث قليلا عن لماذا نحن بحاجة إلى استجابة الجسم أو معيار واحد مخصص. لطلبات GET، هذا واضح جدا، ونحن في حاجة الى ارسال XML / JSON محتوى بدلا من صفحة الحالة (قدم طلب وكان ساري المفعول). ومع ذلك، هناك أيضا وظائف للتعامل معها. داخل من تطبيقات الخاصة بك، عند إنشاء الكيان الجديد، الذي جلب على الأرجح هوية الكيان الجديد، عبر ما يشبه mysql_insert_id (). حسنا، إذا كان مستخدم المشاركات إلى API الخاص بك، وأنها سوف ربما تريد أن الهوية الجديدة كذلك. ماذا سأفعل عادة في هذه الحالة يتم إرسال ببساطة الهوية الجديدة باعتبارها الهيئة (مع رمز حالة 201)، ولكن هل يمكن أن يلتف أيضا في XML أو JSON إذا كنت تريد.

لذا، دعونا توسيع نطاق التنفيذ لدينا عينة قليلا:

 التبديل ($ البيانات> getMethod)
 {
	 / / هذا هو طلب لجميع المستخدمين، ليست واحدة على وجه الخصوص
	 قضية 'الحصول على':
		 $ user_list getUserList = ()؛ / / نفترض هذا بإرجاع صفيف

		 إذا دولار (البيانات> getHttpAccept == 'سلمان')
		 {
			 RestUtils :: sendResponse (200، json_encode ($ user_list)، 'تطبيق / سلمان')؛
		 }
		 آخر إذا دولار (البيانات> getHttpAccept == 'XML')
		 {
			 / / استخدام حزمة XML_SERIALIZER الكمثرى
			 $ = مجموعة الخيارات
			 (
				 "البادئة '=>' '،
				 'addDecl' => كاذبة،
				 'rootName' => $ FC-> getAction ()،
				 XML_SERIALIZER_OPTION_RETURN_RESULT => صحيح
			 )؛
			 $ = XML_Serializer مسلسل جديد ($ الخيارات)؛

			 RestUtils :: sendResponse (200 $، مسلسل-> تسلسل ($ user_list)، "التطبيق / xml ')؛
		 }

		 كسر؛
	 / / خلق مستخدم جديد
	 قضية 'آخر':
		 $ المستخدم = العضو الجديد ()؛
		 $ للمستخدم> setFirstName ($ البيانات> برنامج GetData () - FIRST_NAME>) / / فقط على سبيل المثال، ينبغي أن يتم هذا النظيف
		 / / وهلم جرا ...
		 $ للمستخدم حفظ <()؛

		 / / مجرد ارسال الهوية الجديدة باعتبارها الهيئة
		 RestUtils :: sendResponse (201 $، للمستخدم> getId ())؛
		 كسر؛
 }

مرة أخرى، وهذا مجرد مثال، ولكنها لا تظهر قبالة (على ما أظن، على الأقل) كم هو قليل ذلك الجهد الذي يستغرقه تنفيذ راحة الاشياء.

وفي ختام

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

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

هل يمكن أن أعتبر خطوة أبعد من ذلك، ومجردة من وحدة تحكم API الخاص بك، ونماذج البيانات أكثر قليلا. بدلا من إنشاء وحدة تحكم بشكل واضح عن كل نموذج البيانات في التطبيق الخاص بك، يمكنك إضافة بعض المنطق في وحدة تحكم API لأول نظرة لتحكم محددة بوضوح، وإذا تم العثور على لا شيء، ومحاولة للبحث عن النموذج القائم. على سبيل المثال، فإن موقع "api/user/1"، يؤدي أولا البحث عن وحدة تحكم "المستخدم" بقية. إذا تم العثور على لا شيء، ويمكن أن ننظر بعد ذلك للحصول على نموذج يسمى "المستخدم" في التطبيق الخاص بك. إذا وجدت واحدة، هل يمكن أن يكتب قليلا من الفودو الآلي لمعالجة جميع الطلبات تلقائيا ضد تلك النماذج.

يذهب إلى أبعد من ذلك، هل يمكن جعل ثم عام "قائمة الجميع" الطريقة التي تعمل على غرار المثال في الفقرة السابقة. ويقول عنوان URL الخاص بك هو "API / المستخدمين". يمكن أن تحكم API تحقق أول وحدة تحكم "المستخدمين" الراحة، وإذا تم العثور على لا شيء، والاعتراف بأن يتم pluaralized المستخدمين، depluralize، ومن ثم نبحث عن نموذج "المستخدم". وإذا ما وجدت واحدة، يتم تحميلها على قائمة لائحة المستخدمين وإرسال هذه قبالة.

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

			 / / معرفة ما اذا كان يتعين علينا أن تتحدى المستخدم
			 إذا كان (فارغة ($ _SERVER ['PHP_AUTH_DIGEST']))
			 {
				 رأس ("HTTP/1.1 401 غير مصرح به ')؛
				 رأس ("مصادقة WWW: نبذة عالم =" '.. AUTH_REALM "" ". uniqid ()'"، qop = "مصادقة"، مناسبة حالية = '، مبهمة = "'.. MD5 (AUTH_REALM) '"') ؛

				 / / وتظهر الخطأ إذا وصلت إلى إلغاء
				 يموت (RestControllerLib :: خطأ (401، صحيح))؛
			 }

			 / / الآن، وanalayze PHP_AUTH_DIGEST فار
			 إذا (($ البيانات = http_digest_parse ($ _SERVER ['PHP_AUTH_DIGEST'])) |! |! $ $ = auth_username البيانات ['المستخدم'])
			 {
				 / / لإظهار الخطأ بسبب مصادقة سيئة
				 يموت (RestUtils :: sendResponse (401))؛
			 }

			 / / حتى الآن، كل ما هو جيد، دعونا الآن تحقق استجابة أكثر قليلا ...
			 $ A1 = MD5 ($ البيانات ['المستخدم'] ':' AUTH_REALM ':'.. $ auth_pass)؛
			 $ A2 = MD5 ($ _SERVER ['REQUEST_METHOD'] ':'. $ البيانات ['أوري'])؛
			 $ valid_response = MD5 ($ A1. ':' $ البيانات ['مناسبة حالية']. ':' $ البيانات ['نورث كارولاينا']. ':' $ البيانات ['cnonce']. ':' $ البيانات. ['qop'] ':' $ A2).

			 / / مشاركة شيك ..
			 إذا دولار (البيانات ['استجابة']! = $ valid_response)
			 {
				 يموت (RestUtils :: sendResponse (401))؛
			 }

الاشياء باردة جدا، أليس كذلك؟ مع قليلا من رمز وبعض منطق ذكي، يمكنك إضافة REST API تعمل بكامل طاقتها لتطبيقات الخاصة بك بشكل سريع جدا. نفذت أنا لا أقول فقط أن لcheerlead مفهوم سواء، وهذه الاشياء في واحدة من الأطر نظري الشخصية في يوم واحد حوالي نصف، ثم أمضى نصف يوم آخر مضيفا كل أنواع السحر بارد لذلك. إذا كنت (القارئ) مهتما في رؤية تنفيذ قراري النهائي، قطرة لي ملاحظة في التعليقات وسأكون سعيدا لتقاسمها مع لكم! أيضا، إذا كنت قد حصلت على أي أفكار باردة كنت ترغب في المشاركة، ومن المؤكد أن تتخلى عن تلك الواردة في التعليقات كذلك ... إذا كنت ترغب في ذلك بما فيه الكفاية، فما استقاموا لكم فاستقيموا تدع حتى تقوم بتأليف الضيف المادة الخاصة حول هذا الموضوع!

حتى المرة القادمة ...

UPDATE: إن كثيرا طلبا للمتابعة لهذه المادة قد تم نشرها: تقديم طلبات مريح في PHP