يجب أن تعتمد واجهة برمجة تطبيقات REST على النص التشعبي

"وهل صدقته؟" قال أمين المظالم هوف بعبارة. "حسنًا ، ما رأيك ، هل كنت قد أخذت هذه الأوزان دون إذنك؟"

"إذن أخذت الأوزان؟" بكى أوستاب. - لماذا؟

- قال بانيكوفسكي أنهم من الذهب.

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

مع هذا الجزء من الكلاسيكيات ، أود أن أبدأ في ترجمة منشور مدونة Roy T. Fielding يجب أن تكون واجهات برمجة تطبيقات REST مدفوعة بالنص التشعبي. شكر خاص لـ habr.com/users/arthuriantech على الرابط إلى المادة.

تم وضع علامة على هذا الأسبوع على Habré باعتباره أسبوع REST (Full) API. بهذا المعنى ، كنت مرتبكًا دائمًا بسبب وجود بادئة REST في هذا المصطلح. وكما اتضح ، ليس أنا فقط. اليوم سوف أقرأها بنفسي وأدعو الجميع لمعرفة ما فكر به روي ت. فيلدنج في عام 2008. بالطبع ، يزحف أحدهم بعصبية على مقعد ويقول: أخبر روي ، تعرف Benya عن واجهة برمجة تطبيقات REST. ومع ذلك ، سنبدأ.

لقد شعرت بالإحباط من فكرة عدد الأشخاص الذين يطلقون على أي واجهة بناءً على بروتوكول HTTP REST API. مثال اليوم هو REST SocialSite API. هذا هو RPC. هذا هو RPC صارخ. يوضح هذا الارتباطات الثابتة أن الوقت قد حان له لتعيين فئة الإباحية الثابت.

ما الذي يجب القيام به حتى يفهموا أن النص التشعبي عنصر ضروري في بنية REST؟ بمعنى آخر ، إذا كانت آلية حالة التطبيق (وبالتالي API) لا تستند إلى نص تشعبي ، فلا يمكن أن تكون RESTful ولا يمكن أن تكون REST API. النقطة. ما الكتاب الذي يجب أن أعد كتابته لتوضيحه؟

مطورو API ، انتبه للقواعد التالية قبل استدعاء تصميمات REST API الخاصة بك:

لا ينبغي أن تعتمد واجهة برمجة تطبيقات REST على بروتوكول اتصال معين ، على الرغم من أن تعيينها الناجح لهذا البروتوكول قد يعتمد على توفر البيانات الوصفية ، واختيار الأساليب ، وما إلى ذلك. بشكل عام ، يجب أن يسمح أي بروتوكول في مخطط URI باستخدام أي مخطط URI لتحديد الهوية. [الخطأ هنا هو أن التعريف ليس منفصلاً عن التفاعل.]

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

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

لا ينبغي أن تحدد واجهة برمجة التطبيقات (REST) ​​أسماء موارد ثابتة أو مساحات أسماء (اتصال عميل خادم ضيق). يجب أن تتمتع الخوادم بحرية إدارة مساحات الأسماء الخاصة بها. بدلاً من ذلك ، اسمح للخوادم بإرشاد العملاء حول كيفية إنشاء URIs المناسبة ، على سبيل المثال ، في نماذج HTML وقوالب URI ، وتحديد هذه الإرشادات في أنواع الوسائط والعلاقات المرجعية. [الخطأ هنا هو أن هيكل المورد قد تم تعيينه خارج هذا المورد ، على سبيل المثال ، في معيار خاص بالمجال ، وهو في الواقع تناظر العلاقة الوظيفية RPC].

يجب ألا تحتوي واجهة برمجة تطبيقات REST على موارد "مكتوبة" ذات أهمية للعميل. يمكن لمؤلفي المواصفات استخدام أنواع الموارد لوصف تنفيذ الخادم خلف الواجهة ، ولكن يجب أن تكون هذه الأنواع غير ملائمة وغير مرئية للعميل. الأنواع الوحيدة التي تهم العميل هي نوع الوسائط لطريقة العرض الحالية وأسماء العلاقات الموحدة. [V. أعلاه]

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

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

أثار هذا المنشور من قبل روي ت. فيلدنج مناقشة في التعليقات. أقترح التعرف على جزء المناقشة ، الذي صاحبته إجابات المؤلف.

السؤال:

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

الجواب هو:

لديّ شريحة في حديثي REST تشرح معنى النص التشعبي (والوسائط التشعبية).

يحتوي النص التشعبي على العديد من التعريفات:

كان تعريف تيد نيلسون الأولي يركز على الوثائق غير الخطية.

أقصد بكلمة "النص التشعبي" وثيقة غير خطية - نص يتفوق على القارئ ويسمح له بالاختيار ، وثيقة يسهل قراءتها على شاشة تفاعلية. من المقبول عمومًا أن هذا عبارة عن سلسلة من كتل النصوص المرتبطة بروابط توفر للقارئ طرقًا متعددة. [ثيودور ه. نيلسون]


أصبح النص التشعبي لاحقًا مرتبطًا بآلية واجهة مستخدم محددة.

النص التشعبي عبارة عن وسيط تخزين مدعوم بالحاسوب يتم عرض المستندات ذات الصلة به مع ارتباطاتها على شاشة كمبيوتر عالية الدقة. [جيفري كونكلين]


عندما أقول "نص تشعبي" ، أقصد العرض التقديمي المتزامن للمعلومات وعناصر التحكم بطريقة تجعل المعلومات متاحة ، وذلك بفضل اختيار المستخدم (أو الجهاز) واختيار الإجراءات. Hypermedia هي ببساطة امتداد لما يعنيه النص لتضمين نقاط ربط مؤقتة في دفق الوسائط ؛ رفض معظم الباحثين هذا التمييز.

ليس من الضروري أن يكون النص التشعبي HTML للمستعرض. يمكن للأجهزة تتبع الروابط عندما يفهمون تنسيق البيانات وأنواع العلاقة.

ديف جونسون (مؤلف واجهة برمجة التطبيقات الانتقادية):

ربما أعطيت صيغة غامضة. لم أقصد مطلقًا الادعاء بأن واجهات برمجة تطبيقات OpenSocial أو SocialSite RPC كانت مريحة. المزيد على مدونتي الأسطوانة rollweblogger.org/roller/entry/the_x_rated_socialsite_api .

الجواب هو:

بروتوكول OpenSocial RESTful ليس RESTful. يمكن إصلاح ذلك من خلال تغييرات صغيرة نسبيًا ، ولكن في الوقت الحالي ، يتم تعبئة نتائج RPC في أنواع شائعة من وسائط الويب.

واجهة برمجة تطبيقات RESTful الحقيقية تشبه النص التشعبي. تحمل كل وحدة معلومات قابلة للمعالجة عنوانًا ، إما صراحة (على سبيل المثال ، سمات الرابط والمعرّف) أو ضمنيًا (على سبيل المثال ، تم الحصول عليها من تعريف نوع البنية المتوسطة والعرض التقديمي). يتم تمثيل نتائج الاستعلام من خلال قائمة الارتباطات التي تحتوي على معلومات موجزة ، بدلاً من صفائف تمثيل الكائنات (لا يحل الاستعلام محل تعريف المورد). تمثل عمليات تمثيل الموارد وثائق ذاتية: لا يحتاج العميل إلى معرفة ما إذا كان هذا المورد هو OpenSocialist ، لأنه يؤثر ببساطة على التمثيلات المستلمة.

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

روابط مفيدة:
1. إصدار الترجمة من habr.com/us/users/arthuriantech

2. نفس أطروحة روي القديمة