كيف يمكنك تنفيذ نماذج "تحرير" الموارد بطريقة RESTful؟

Question

نحن نحاول تنفيذ REST API لتطبيق لدينا الآن.نريد الكشف عن إمكانيات القراءة/الكتابة لمختلف الموارد باستخدام REST API.كيف ننفذ الجزء "النموذجي" من هذا؟أحصل على كيفية الكشف عن "قراءة" بياناتنا عن طريق إنشاء عناوين URL RESTful التي تعمل بشكل أساسي كاستدعاءات للطرق وإرجاع البيانات:

GET /restapi/myobject?param=object-id-maybe

... ويتم إرجاع مستند XML يمثل بعض بنية البيانات.بخير.

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

لكنني لا أفهم كيف ستفعل الشيء نفسه مع أساليب HTTP التي تم تعيين REST لها نوعًا ما.إنها عملية PUT، أليس كذلك؟يمكن للشخص أن يفسر هذا؟

(اعتبار إضافي:سيتم تنفيذ واجهة المستخدم بشكل أساسي باستخدام AJAX)

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

Answer 1

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

إذا كنت تستخدم كائن XmlHttpRequest، فيمكنك تعيين الطريقة على PUT وإرسال البيانات إلى URI الخاص بالمورد.يمكن أن يعمل هذا أيضًا مع النماذج الفارغة إذا قام الخادم بتوفير عنوان URI صالح للمورد غير الموجود بعد.سيؤدي PUT الأول إلى إنشاء المورد (إرجاع 202).لن تفعل عمليات PUT اللاحقة شيئًا إذا كانت نفس البيانات أو تعدل المورد الموجود (في كلتا الحالتين 200 يتم إرجاعها ما لم يحدث خطأ).

Answer 2

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

 Operate on a Record

GET /people/1
    return the first record 
DELETE /people/1
    destroy the first record 
POST /people/1?_method=DELETE
    alias for DELETE, to compensate for browser limitations 

GET /people/1/edit
    return a form to edit the first record 
PUT /people/1
    submit fields for updating the first record 
POST /people/1?_method=PUT
    alias for PUT, to compensate for browser limitations 

Answer 3

أعتقد أنك بحاجة إلى فصل خدمات البيانات عن واجهة مستخدم الويب.عند توفير خدمات البيانات، يكون نظام RESTful مناسبًا تمامًا، بما في ذلك استخدام الأفعال التي لا تدعمها المتصفحات (مثل PUT وDELETE).

عند وصف واجهة المستخدم، أعتقد أن معظم الناس يخلطون بين "RESTful" و"عناوين URL الرائعة التي يمكن التنبؤ بها".لن أشعر بالقلق الشديد بشأن بناء جملة عنوان URL RESTful البحت عندما تصف واجهة مستخدم الويب.

Answer 4

يجب أن يكون التحميل مجرد طلب GET عادي، ويجب أن يكون حفظ البيانات الجديدة عبارة عن POST إلى عنوان URL الذي يحتوي على البيانات حاليًا...

على سبيل المثال، قم بتحميل البيانات الحالية من http://www.example.com/record/matt-s-example ثم قم بتغيير البيانات، ثم قم بالنشر مرة أخرى إلى نفس عنوان URL مع البيانات الجديدة.

يمكن استخدام طلب PUT عند إنشاء سجل جديد (أي.ضع البيانات على عنوان URL غير موجود حاليًا)، ولكن من الناحية العملية ربما يكون مجرد النشر هو الأسلوب الأفضل للبدء به.