http ما هي بالضبط برمجة RESTful؟




definition (24)

ما هي بالضبط برمجة RESTful؟


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

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

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

على سبيل المثال ، دعونا نتخيل أن لدينا قاعدة بيانات مستخدم يتم إدارتها بواسطة خدمة ويب. تستخدم خدمتنا الوسائط التشعبية المخصصة استنادًا إلى JSON ، والتي نعين لها تطبيق mimetype / json + userdb (قد يكون هناك أيضًا تطبيق / xml + userdb و application / whatever + userdb - قد يتم دعم العديد من أنواع الوسائط). تمت برمجة كل من العميل والخادم لفهم هذا التنسيق ، لكن لا يعرفان شيئًا عن بعضهما. كما يشير roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven :

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

قد يؤدي طلب المورد الأساسي / إلى عرض شيء مثل هذا:

طلب

GET /
Accept: application/json+userdb

استجابة

200 OK
Content-Type: application/json+userdb

{
    "version": "1.0",
    "links": [
        {
            "href": "/user",
            "rel": "list",
            "method": "GET"
        },
        {
            "href": "/user",
            "rel": "create",
            "method": "POST"
        }
    ]
}

نعرف من وصف وسائل الإعلام لدينا أنه يمكننا العثور على معلومات حول الموارد ذات الصلة من الأقسام المسماة "الروابط". وهذا ما يسمى التحكم في الوسائط التشعبية . في هذه الحالة ، يمكننا أن نحدد من خلال هذا القسم أنه يمكننا العثور على قائمة مستخدمين من خلال تقديم طلب /user :

طلب

GET /user
Accept: application/json+userdb

استجابة

200 OK
Content-Type: application/json+userdb

{
    "users": [
        {
            "id": 1,
            "name": "Emil",
            "country: "Sweden",
            "links": [
                {
                    "href": "/user/1",
                    "rel": "self",
                    "method": "GET"
                },
                {
                    "href": "/user/1",
                    "rel": "edit",
                    "method": "PUT"
                },
                {
                    "href": "/user/1",
                    "rel": "delete",
                    "method": "DELETE"
                }
            ]
        },
        {
            "id": 2,
            "name": "Adam",
            "country: "Scotland",
            "links": [
                {
                    "href": "/user/2",
                    "rel": "self",
                    "method": "GET"
                },
                {
                    "href": "/user/2",
                    "rel": "edit",
                    "method": "PUT"
                },
                {
                    "href": "/user/2",
                    "rel": "delete",
                    "method": "DELETE"
                }
            ]
        }
    ],
    "links": [
        {
            "href": "/user",
            "rel": "create",
            "method": "POST"
        }
    ]
}

يمكننا أن نخبر الكثير من هذا الرد. على سبيل المثال ، نحن نعلم الآن أنه يمكننا إنشاء مستخدم جديد بواسطة POSTing إلى /user :

طلب

POST /user
Accept: application/json+userdb
Content-Type: application/json+userdb

{
    "name": "Karl",
    "country": "Austria"
}

استجابة

201 Created
Content-Type: application/json+userdb

{
    "user": {
        "id": 3,
        "name": "Karl",
        "country": "Austria",
        "links": [
            {
                "href": "/user/3",
                "rel": "self",
                "method": "GET"
            },
            {
                "href": "/user/3",
                "rel": "edit",
                "method": "PUT"
            },
            {
                "href": "/user/3",
                "rel": "delete",
                "method": "DELETE"
            }
        ]
    },
    "links": {
       "href": "/user",
       "rel": "list",
       "method": "GET"
    }
}

نعلم أيضًا أنه يمكننا تغيير البيانات الحالية:

طلب

PUT /user/1
Accept: application/json+userdb
Content-Type: application/json+userdb

{
    "name": "Emil",
    "country": "Bhutan"
}

استجابة

200 OK
Content-Type: application/json+userdb

{
    "user": {
        "id": 1,
        "name": "Emil",
        "country": "Bhutan",
        "links": [
            {
                "href": "/user/1",
                "rel": "self",
                "method": "GET"
            },
            {
                "href": "/user/1",
                "rel": "edit",
                "method": "PUT"
            },
            {
                "href": "/user/1",
                "rel": "delete",
                "method": "DELETE"
            }
        ]
    },
    "links": {
       "href": "/user",
       "rel": "list",
       "method": "GET"
    }
}

لاحظ أننا نستخدم أفعال HTTP مختلفة (GET و PUT و POST و DELETE وغيرها) للتلاعب بهذه الموارد ، وأن المعرفة الوحيدة التي نفترضها على جزء العملاء هي تعريفنا لوسائل الإعلام.

قراءة متعمقة:

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


أود أن أقول أن برمجة RESTful ستكون حول إنشاء الأنظمة (API) التي تتبع النمط المعماري REST.

لقد عثرت على هذا البرنامج التعليمي الرائع والقصير والسهل لفهم REST بواسطة Dr. M. Elkstein ونقتبس الجزء الأساسي الذي سيجيب عن سؤالك في أغلب الأحيان:

http://rest.elkstein.org/

REST هو نمط هندسة لتصميم التطبيقات المتصلة بالشبكة. تتمثل الفكرة في أنه بدلاً من استخدام آليات معقدة مثل CORBA أو RPC أو SOAP للاتصال بين الأجهزة ، يتم استخدام HTTP البسيط لإجراء مكالمات بين الأجهزة.

  • في العديد من الطرق ، يمكن اعتبار شبكة الويب العالمية نفسها ، القائمة على HTTP ، بمثابة بنية قائمة على أساس REST.

تستخدم تطبيقات RESTful طلبات HTTP لنشر البيانات (إنشاء و / أو تحديث) ، وقراءة البيانات (مثل إجراء الاستعلامات) ، وحذف البيانات. وبالتالي ، يستخدم REST HTTP لكافة عمليات CRUD الأربعة (إنشاء / قراءة / تحديث / حذف).

لا أعتقد أنك يجب أن تشعر بالغباء لعدم سماعك عن REST خارج ... ، سأكون في نفس الموقف! إن الإجابة على سؤال الـ SO هذا حول لماذا أصبح REST أكبر الآن يمكن أن يخفف بعض المشاعر.


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


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

ريتشاردسون نموذج النضج


السؤال القديم ، طريقة جديدة للإجابة. هناك الكثير من المفاهيم الخاطئة حول هذا المفهوم. أحاول دائمًا أن أتذكر:

  1. لا تعتبر عناوين URL المنظمة وطرق المتشعب / الأفعال تعريفًا للبرامج المريحة.
  2. JSON ليست برمجة مريحة
  3. برمجة RESTful ليست لواجهة برمجة التطبيقات

أنا أعرّف البرمجة المريحة

يكون التطبيق مريحًا إذا كان يوفر موارد (كونه مجموعة من عناصر التحكم في نقل البيانات + الحالة) في نوع وسائط يفهمها العميل

لكي تكون مبرمجًا مريحًا ، يجب أن تحاول إنشاء تطبيقات تتيح للممثلين القيام بالأشياء. ليس مجرد تعريض قاعدة البيانات.

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

أنا لا أبحث عن تعزيز الذات ، ولكن أنا أتوسع في هذه الأفكار إلى عمق كبير في كلامي http://techblog.bodybuilding.com/2016/01/video-what-is-restful-200.html .


REST === تشبيه HTTP غير صحيح حتى لا تشدد على حقيقة أنه "يجب" أن تكون مدفوعة HATEOAS .

روي نفسه مسحها roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven .

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

[الفشل هنا يعني أن المعلومات خارج النطاق تقود التفاعل بدلاً من النص التشعبي.]


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

لقد كان أفضل نهج عملي للتعامل مع التغييرات الأساسية للبرمجة في عصر الإنترنت. فيما يتعلق بالتغييرات الأساسية ، قام إريك ماير بمناقشة حول العرض هنا: http://www.infoq.com/interviews/erik-meijer-programming-language-design-effects-purity#view_93197 . يلخصه كآثار خمسة ، ويقدم حلاً من خلال تصميم الحل في لغة برمجة. يمكن تحقيق الحل أيضًا في النظام الأساسي أو مستوى النظام ، بغض النظر عن اللغة. يمكن اعتبار الراحة واحدة من الحلول التي كانت ناجحة للغاية في الممارسة الحالية.

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

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

فقط بلدي 2C.

تحرير: جهازي أكثر أهمية:


أرى مجموعة من الإجابات التي تقول أن وضع كل شيء حول المستخدم 123 في المورد "/ المستخدم / 123" هو RESTful.

يقول روي فيلدنغ ، الذي صاغ هذا المصطلح ، أن roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven . على وجه الخصوص ، "يجب ألا تقوم واجهة برمجة التطبيقات لـ REST بتعريف أسماء المصادر الثابتة أو التسلسلات الهرمية".

لذلك إذا كان مسارك "/ user / 123" ثابتًا على العميل ، فلن يكون RESTful حقًا. استخدام جيد لبروتوكول HTTP ، ربما ، ربما لا. لكن ليس RESTful. يجب أن يأتي من النص التشعبي.


يستخدم REST أساليب HTTP المختلفة (بشكل رئيسي GET / PUT / DELETE) لمعالجة البيانات.

بدلاً من استخدام عنوان URL محدد لحذف طريقة (على سبيل المثال ، /user/123/delete ) ، يمكنك إرسال طلب DELETE إلى /user/[id] URL ، لتحرير مستخدم ، لاسترداد معلومات عن مستخدم ترسله طلب GET إلى /user/[id]

على سبيل المثال ، بدلاً من ذلك مجموعة من عناوين URL التي قد تبدو كالتالي:

GET /delete_user.x?id=123
GET /user/delete
GET /new_user.x
GET /user/new
GET /user?id=1
GET /user/id/1

كنت تستخدم "الأفعال" HTTP ويكون ..

GET /user/2
DELETE /user/2
PUT /user

لا توجد فكرة مثل "برمجة RESTful" في حد ذاتها. سيكون من الأفضل استدعاء نموذج RESTful أو أفضل هندسة RESTful. إنها ليست لغة برمجة. إنه نموذج.

من ويكيبيديا :

في الحوسبة ، نقل الحالة التمثيلية (REST) ​​هو أسلوب معماري يستخدم لتطوير الويب.


أعتذر عما إذا كنت لا أجب عن السؤال مباشرة ، ولكن من السهل فهم كل هذا بمزيد من الأمثلة التفصيلية. ليس من السهل فهم Fielding بسبب كل التجريد والمصطلحات.

هناك مثال جيد إلى حد ما هنا:

شرح REST و Hypertext: Spam-E روبوت تنظيف البريد العشوائي

والأفضل من ذلك ، هناك شرح واضح مع أمثلة بسيطة هنا (نقطة القوة أكثر شمولاً ، ولكن يمكنك الحصول على معظمها في إصدار html):

http://www.xfront.com/REST.ppt أو http://www.xfront.com/REST.html

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

يشرح ذلك المستند xfront الفرق بين REST و SOAP ، وهذا مفيد حقًا أيضًا. عندما يقول Fielding ، " roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven " ، من الواضح أن RPC ليس RESTful ، لذلك من المفيد معرفة الأسباب الدقيقة لذلك. (SOAP نوع من RPC.)


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

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

  • الشرط الأكثر وضوحًا هو أنه يجب أن تكون هناك لغة عالمية من نوع ما بحيث يمكن للخادم أن يخبر العميل بما يحاول القيام به مع الطلب وأن يستجيب للخادم.

  • ولكن للعثور على أي مورد معين ثم إخبار العميل بمكان حياة هذا المورد ، يجب أن يكون هناك طريقة عالمية للإشارة إلى الموارد. هذا هو المكان الذي تأتي به معرفات الموارد العالمية (URIs) ؛ هم في الأساس عناوين فريدة للعثور على الموارد.

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

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

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

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

الآن ، إذا كان كل هذا يبدو مألوفًا ، فعندئذٍ رائع. بروتوكول نقل النص التشعبي (HTTP) ، الذي يحدد بروتوكول الاتصال عبر شبكة الويب العالمية هو تطبيق للمفهوم التجريدي لبنية RESTful (أو مثال لفئة REST إذا كنت من المتعصبين OOP مثلي). في هذا التطبيق لـ REST ، يتفاعل العميل والخادم عبر GET و POST و PUT و DELETE وما إلى ذلك ، والتي تعد جزءًا من اللغة العالمية ويمكن توجيه الموارد إلى استخدام عناوين URL.


برمجة RESTful هي حول:

  • الموارد التي يتم تحديدها من قبل معرف دائم: URIs هو اختيار معرف في كل مكان في كل مكان
  • الموارد التي يتم التلاعب بها باستخدام مجموعة مشتركة من الأفعال: أساليب HTTP هي الحالات التي ينظر إليها بشكل شائع - Create المبتدئ ، Retrieve ، Update ، Delete يصبح POST و GET و PUT و DELETE . لكن REST لا يقتصر على HTTP ، بل هو أكثر وسائل النقل شيوعًا في الوقت الحالي.
  • يعتمد التمثيل الفعلي الذي تم استرداده لمورد ما على الطلب وليس على المعرف: استخدم رؤوس Accept للسيطرة على ما إذا كنت تريد XML أو HTTP أو حتى كائن Java يمثل المصدر
  • الحفاظ على الحالة في الكائن وتمثيل الدولة في التمثيل
  • تمثل العلاقات بين الموارد في تمثيل المورد: يتم تضمين الروابط بين الكائنات مباشرة في التمثيل
  • تصف تمثيلات الموارد كيف يمكن استخدام التمثيل وتحت أي ظروف يجب التخلص منه / إعادة تعبئته بطريقة متسقة: استخدام رؤوس HTTP Cache-Control

ربما يكون الأخير هو الأكثر أهمية من حيث النتائج والفعالية الشاملة لـ REST. بشكل عام ، يبدو أن معظم مناقشات RESTful تركز على HTTP واستخدامها من المتصفح وما لا. أفهم أن R. Fielding صاغ هذا المصطلح عندما وصف الهندسة المعمارية والقرارات التي تؤدي إلى HTTP. أطروحته هي أكثر عن الهندسة المعمارية والذاكرة المؤقتة للموارد من الموارد عن HTTP.

إذا كنت مهتمًا حقًا بماهية بنية RESTful ولماذا تعمل ، اقرأ أطروحته عدة مرات واقرأ كل شيء ليس فقط الفصل الخامس! انظر فيما يلي لماذا يعمل DNS . اقرأ عن التنظيم الهرمي لنظام أسماء النطاقات وكيفية عمل الإحالات. ثم اقرأ ودرس كيف يعمل التخزين المؤقت لنظام أسماء النطاقات. وأخيرًا ، اقرأ مواصفات HTTP ( RFC2616 و RFC3040 وجه الخصوص) RFC3040 كيف ولماذا يعمل التخزين المؤقت بالطريقة التي يعمل بها. في النهاية ، سوف تنقر فقط. كان الوحي النهائي بالنسبة لي عندما رأيت التشابه بين DNS و HTTP. بعد ذلك ، يبدأ فهم ما إذا كانت SOA وواجهات Passing Interfaces قابلة للتوسع.

أعتقد أن أهم خدعة لفهم الآثار المعمارية والأداء المعماري لأبنية RESTful و Shared Nothing هي تجنب التعلق بالتكنولوجيا وتفاصيل التنفيذ. ركز على من يملك الموارد ، ومن المسؤول عن إنشاءها / الحفاظ عليها ، وما إلى ذلك. ثم فكر في التمثيلات والبروتوكولات والتقنيات.


الإجابة بسيطة للغاية ، هناك أطروحة كتبها روي فيلدنغ.] 1 في تلك الرسالة ، يحدد مبادئ REST. إذا كان أحد التطبيقات يفي بكل هذه المبادئ ، فهذا هو تطبيق REST.

roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven بعد ذلك تم استنفاد مصطلح RESTful كذلك. في الوقت الحاضر ، نتحدث عن واجهات برمجة تطبيقات الويب وواجهة برمجة التطبيقات Hypermedia ، لأن معظم ما يسمى تطبيقات REST لم يحقق جزء HATEOAS من قيود الواجهة الموحدة.

قيود REST هي التالية:

  1. بنية العميل الخادم

    لذلك لا يعمل مع مآخذ PUB / SUB ، على أساس REQ / REP.

  2. الاتصال عديم الجنسية

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

  3. استخدام ذاكرة التخزين المؤقت إذا استطعت

    لذلك ليس عليك تقديم نفس الطلبات مرارًا وتكرارًا.

  4. واجهة موحدة كعقد مشترك بين العميل والخادم

    لا يتم المحافظة على العقد بين العميل والخادم بواسطة الخادم. بمعنى آخر ، يجب فصل العميل عن تنفيذ الخدمة. يمكنك الوصول إلى هذه الحالة عن طريق استخدام حلول قياسية ، مثل معيار IRI (URI) لتحديد الموارد ، ومعيار HTTP لتبادل الرسائل ، وأنواع MIME القياسية لوصف تنسيق تسلسل الجسم ، والبيانات الوصفية (من المحتمل أن تكون vocabs RDF ، microformats ، وما إلى ذلك) وصف دلالات الأجزاء المختلفة من نص الرسالة. لفصل بنية IRI من العميل ، يجب عليك إرسال ارتباطات تشعبية إلى العملاء في تنسيقات hypermedia مثل (HTML ، JSON-LD ، HAL ، إلخ). لذلك يمكن للعميل استخدام البيانات الوصفية (ربما علاقات الارتباط ، vocabs RDF) المعينة للارتباطات التشعبية للتنقل في جهاز الدولة للتطبيق من خلال التحولات المناسبة للدولة من أجل تحقيق هدفها الحالي.

    على سبيل المثال عندما يرغب أحد العملاء بإرسال طلب إلى متجر ويب ، يجب عليه التحقق من الارتباطات التشعبية الموجودة في الردود المرسلة من قبل webshop. من خلال فحص الروابط ، يتم العثور على أحد الروابط الموضحة في http://schema.org/OrderAction . العميل يعرف vocab schema.org ، لذلك يفهم أنه من خلال تفعيل هذا الارتباط التشعبي سترسل الطلب. لذلك ينشط الارتباط التشعبي ويرسل رسالة POST https://example.com/api/v1/order مع النص الصحيح. بعد ذلك تعالج الخدمة الرسالة وتستجيب للنتيجة برأسية HTTP المناسبة ، على سبيل المثال 201 - created بنجاح. للتعليق على الرسائل بالبيانات الوصفية المفصلة ، الحل القياسي لاستخدام تنسيق RDF ، على سبيل المثال JSON-LD مع REST vocab ، على سبيل المثال Hydra و vocabs خاصة بالنطاق مثل schema.org أو أي مفردات أخرى مرتبطة بالبيانات ، وربما vocab مخصص للتطبيق المخصص إذا بحاجة. الآن هذا ليس بالأمر السهل ، وهذا هو السبب في أن معظم ppl يستخدم HAL وتنسيقات بسيطة أخرى والتي عادة ما توفر فقط فوكب REST ، ولكن لا يوجد دعم للبيانات المرتبطة.

  5. بناء نظام الطبقات لزيادة قابلية التوسع

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

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

  6. رمز على الطلب لتوسيع وظائف العميل

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

تؤدي قيود REST إلى نظام قابل للتطور بشكل كبير حيث يتم فصل العملاء عن تطبيقات الخدمات. لذلك يمكن أن يكون العملاء قابلين لإعادة الاستخدام ، تمامًا مثل المتصفحات على الويب. يتشارك العملاء والخدمات نفس المعايير والمفردات ، حتى يتمكنوا من فهم بعضهم البعض على الرغم من حقيقة أن العميل لا يعرف تفاصيل تنفيذ الخدمة. وهذا يجعل من الممكن إنشاء عملاء مؤتملين يمكنهم العثور على خدمات REST واستخدامها لتحقيق أهدافهم. على المدى الطويل ، يستطيع هؤلاء العملاء التواصل مع بعضهم البعض والثقة ببعضهم البعض بالمهام ، تمامًا كما يفعل البشر. إذا أضفنا أنماط التعلم إلى مثل هؤلاء العملاء ، فإن النتيجة ستكون واحدة أو أكثر من الذكاء الاصطناعي باستخدام شبكة الأجهزة بدلاً من مجمع خادم واحد. في النهاية حلم بيرنرز لي:فالشبكة الدلالية والذكاء الاصطناعي سيكونان حقيقة. لذلك في عام 2030 ، انتهى بنا المطاف إلى إنهاء Skynet. حتى ذلك الوقت ... ؛-)


REST هو النمط المعماري ونمط كتابة التطبيقات الموزعة. إنه ليس أسلوب برمجة بالمعنى الضيق.

القول بأنك تستخدم أسلوب REST يشبه القول بأنك بنيت منزلًا بأسلوب معين: على سبيل المثال Tudor أو Victorian. يمكن تعريف كل من REST كأسلوب للبرمجيات وتيودور أو الفيكتوري كأسلوب المنزل من خلال الصفات والقيود التي تجعلها. على سبيل المثال ، يجب أن يكون لدى REST فصل Client Server حيث تقوم الرسائل بالوصف الذاتي. المنازل ذات النمط تيودور لديها الجملونات المتراكبة والسقوف التي تنحدر بشكل حاد مع الجملونات التي تواجه الجبهة. يمكنك قراءة أطروحة روي لمعرفة المزيد عن القيود والصفات التي تشكل REST.

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

علاوة:

تعتمد شبكة الويب بأكملها على REST (أو REST مستندة إلى الويب). لذلك ، قد ترغب في معرفة ذلك كمطور ويب ، على الرغم من أنه ليس من الضروري كتابة تطبيقات ويب جيدة.


REST هو أسلوب معماري يعتمد على معايير الويب وبروتوكول HTTP (تم تقديمه في عام 2000).

في بنية REST ، كل شيء مورد (Users، Orders، Comments). يتم الوصول إلى مورد عبر واجهة مشتركة تعتمد على أساليب HTTP القياسية (GET ، PUT ، PATCH ، DELETE ، الخ).

في بنية REST تستند لديك ملقم REST الذي يوفر الوصول إلى الموارد. يمكن لعميل REST الوصول إلى موارد REST وتعديلها.

يجب أن يدعم كل مورد عمليات HTTP الشائعة. يتم تحديد الموارد من خلال المعرفات العمومية (وهي عادة عناوين URI).

يسمح REST بأن تحتوي الموارد على تمثيلات مختلفة ، على سبيل المثال ، text ، XML ، JSON إلخ. يمكن لعميل REST طلب تمثيل محدد عبر بروتوكول HTTP (التفاوض على المحتوى).

أساليب HTTP:

يتم استخدام أساليب PUT و GET و POST و DELETE بشكل نموذجي في البنى القائمة على REST. يعطي الجدول التالي شرحًا لهذه العمليات.

  • تعرف GET وصول القراءة للمورد بدون آثار جانبية. لا يتم تغيير المورد أبداً عبر طلب GET ، على سبيل المثال ، ليس للطلب أي آثار جانبية (idempotent).
  • PUT يخلق مورد جديد. كما يجب أن يكون عديم القوة.
  • DELETE يزيل الموارد. العمليات عاطلة. يمكن أن تتكرر دون أن تؤدي إلى نتائج مختلفة.
  • يقوم POST بتحديث مورد موجود أو إنشاء مورد جديد.

كتاب عظيم عن REST هو REST في الممارسة .

يجب أن يقرأ ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

راجع مقال Martin Fowlers نموذج Richardson Maturity (RMM) للحصول على شرح حول خدمة RESTful.

أن تكون RESTful يجب أن تحقق الخدمة Hypermedia كمحرك لدولة التطبيق. (HATEOAS) ، أي أنها تحتاج للوصول إلى المستوى 3 في RMM ، اقرأ المقال للحصول على التفاصيل أو الشرائح من محادثة qcon .

القيد HATEOAS هو اختصار ل Hypermedia كمحرك لدولة التطبيق. هذا المبدأ هو الاختلاف الرئيسي بين REST ومعظم الأشكال الأخرى من نظام خادم العميل.

...

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

اختبار REST Litmus لأطر الويب هو اختبار نضج مماثل لأطر الويب.

الاقتراب من REST النقي: تعلم أن الحب HATEOAS هو عبارة عن مجموعة جيدة من الروابط.

يناقش REST مقابل SOAP لـ Public Cloud المستويات الحالية لاستخدام REST.

يناقش REST و versioning قابلية التوسعة ، الإصدار ، القدرة على التطور ، إلخ من خلال التعديل


ما هو REST؟

REST بكلمات رسمية ، REST هو أسلوب معماري مبني على مبادئ معينة باستخدام أساسيات "الويب" الحالية. هناك 5 أساسيات أساسية للويب يتم الاستفادة منها لإنشاء خدمات REST.

  • المبدأ 1: كل شيء هو مورد في نمط REST المعماري ، تعتبر البيانات والوظائف موارد ويتم الوصول إليها باستخدام معرفات الموارد المنتظمة (URIs) ، وعادة ما ترتبط على الويب.
  • المبدأ 2: يتم تحديد كل مورد بواسطة معرف فريد (URI)
  • المبدأ 3: استخدام واجهات بسيطة وموحدة
  • المبدأ 4: التواصل يتم عن طريق التمثيل
  • المبدأ 5: كن عديم الجنسية

REST تعني نقل الحالة التمثيلي .

وهو يعتمد على بروتوكول اتصالات عديم الجنسية ، خادم العميل ، وقابل للتخزين المؤقت - وفي جميع الحالات تقريبا ، يتم استخدام بروتوكول HTTP.

غالبًا ما يستخدم REST في تطبيقات الهاتف المحمول ومواقع ويب الشبكات الاجتماعية وأدوات المزج وعمليات الأعمال الآلية. يؤكد أسلوب REST على أن التفاعلات بين العملاء والخدمات يتم تعزيزها من خلال وجود عدد محدود من العمليات (الأفعال). يتم توفير المرونة عن طريق تخصيص الموارد (الأسماء) لمؤشرات الموارد العالمية الفريدة الخاصة بها (URIs).

مقدمة عن الراحة


إنها البرمجة حيث تتلاءم بنية النظام الخاص بك مع ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm وضعه روي فيلدنغ في أطروحته . بما أن هذا هو النمط المعماري الذي يصف الويب (أكثر أو أقل) ، فإن الكثير من الناس يهتمون به.

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


RESTful برمجة API ( RESTful (نقل الحالة التمثيلية) بكتابة تطبيقات الويب في أي لغة برمجة من خلال اتباع 5 مبادئ أسلوب معماري للبرنامج الأساسي :

  1. الموارد (البيانات والمعلومات).
  2. معرف عالمي فريد (جميع الموارد فريدة يتم تحديدها بواسطة URI ).
  3. واجهة موحدة - استخدام واجهة بسيطة قياسية (HTTP).
  4. التمثيل - يتم كل الاتصالات من خلال التمثيل (مثل XML / JSON )
  5. Stateless (كل طلب يحدث في عزلة تامة ، يسهل تخزينها مؤقتًا وتحميل التوازن) ،

بعبارة أخرى ، أنت تكتب تطبيقات شبكة بسيطة من نقطة إلى نقطة عبر HTTP تستخدم أفعال مثل GET أو POST أو PUT أو DELETE من خلال تنفيذ هندسة RESTful التي تقترح توحيد الواجهة التي يكشفها كل "مورد". لا شيء هو أن استخدام الميزات الحالية للويب بطريقة بسيطة وفعالة (بنية ناجحة للغاية ومثبتة وموزعة). وهو بديل عن آليات أكثر تعقيدًا مثل SOAP و CORBA و RPC .

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


REST هو نمط معماري لأنظمة البرامج الموزعة (مثل WWW) ، يمكنك أن تتخيل أنها قواعد تطبيق ويب مصممة تصميماً جيداً: مجموعة من صفحات ويب الإنترنت (جهاز الحالة الظاهرية) ، والتي فيها ارتباط تشعبي بالنقر فوق الارتباط (نقل الحالة ) ، والنتيجة هي صفحة الويب التالية (مما يعني الحالة التالية للتطبيق).

تصف REST نظام الشبكة يتكون من ثلاثة أجزاء:

  1. عناصر البيانات (الموارد ، معرّف الموارد ، التمثيل)
  2. الموصلات (العميل ، الخادم ، ذاكرة التخزين المؤقت ، المحلل ، النفق)
  3. المكونات (خادم المصدر ، والبوابة ، والوكيل ، ووكيل المستخدم)

يستوفي REST بدقة الشروط التالية:

  1. يتم تقسيم حالة وظيفة التطبيق إلى موارد
  2. كل مورد يستخدم كتركيب لوضعية الروابط التشعبية (أي في UW WWW)
  3. تشترك جميع الموارد في واجهة موحدة بين العميل مع حالة انتقال المورد ، بما في ذلك:
    1. مجموعة محدودة من العمليات المحددة جيداً (أي في HTTP GET / POST / PUT / DELETE)
    2. مجموعة محدودة من أنواع محتوى تنسيق المحتوى ، والتي قد تتضمن تعليمات برمجية قابلة للتنفيذ (على سبيل المثال ، في Javascript WWW)

هذا هو "نقاش" طويل مثير للدهشة ومربك للغاية على أقل تقدير.

IMO:

1) لا يوجد شيء مثل برمجة مريحة ، دون مشترك كبير والكثير من البيرة :)

2) نقل الحالة التمثيلي (REST) ​​هو أسلوب معماري محدد في أطروحة Roy Fielding . لديها عدد من القيود. إذا كانت الخدمة / العميل الخاص بك يحترم تلك الشروط ، فحينها يكون RESTful. هذه هي.

يمكنك تلخيص (بشكل ملحوظ) القيود على:

  • الاتصال عديم الجنسية
  • احترام مواصفات HTTP (إذا تم استخدام HTTP)
  • بوضوح ينقل تنسيقات المحتوى المنقولة
  • استخدام الوسائط التشعبية كمحرك لحالة التطبيق

هناك roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven أخرى roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven تشرح الأمور بشكل جيد.

الكثير من الإجابات نسخ / لصق معلومات صالحة تمزجها وإضافة بعض الارتباك. يتحدث الناس هنا عن المستويات ، حول RESTFul URIs (لا يوجد شيء من هذا القبيل!) ، وتطبيق أساليب HTTP GET ، POST ، PUT ... REST لا يتعلق بذلك أو ليس فقط حول ذلك.

على سبيل المثال الروابط - من الجميل أن يكون لديك واجهة برمجة تطبيقات جميلة المظهر ولكن في النهاية لا يعتني العميل / الخادم بالارتباطات التي تحصل عليها / يرسلها هو المحتوى المهم.

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


يدعو النمط المعماري المسمى REST (نقل الحالة التمثيلي) إلى أن تطبيقات الويب يجب أن تستخدم HTTP كما كان متوقعًا في الأصل . يجب أن تستخدم عمليات البحث طلبات GET . يجب استخدام GET للطفرة ، والحذف ، والحذف على التوالي .

يميل مؤيدو REST إلى تفضيل عناوين URL ، مثل

http://myserver.com/catalog/item/1729

ولكن لا تتطلب بنية REST هذه "عناوين URL الرائعة". طلب GET مع معلمة

http://myserver.com/catalog?item=1729

هو كل شيء مثل RESTful.

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

http://myserver.com/addToCart?cart=314159&item=1729

لن يكون مناسبا. يجب أن تكون طلبات GET idempotent . أي أن إصدار طلب مرتين يجب ألا يختلف عن إصداره مرة واحدة. هذا ما يجعل الطلبات قابلة للتخزين المؤقت. طلب "إضافة إلى عربة التسوق" ليس مطلقًا - حيث يؤدي إصداره مرتين إلى إضافة نسختين من العنصر إلى سلة التسوق. من الواضح أن طلب POST مناسب في هذا السياق. وبالتالي ، يحتاج تطبيق الويب RESTful إلى نصيبه من طلبات POST.

هذا مأخوذ من الكتاب الرائع Core JavaServer يواجه كتاب David M. Geary.





definition