وضع مقابلبعد في بقية

Question

وفقا HTTP/1.1 المواصفات:

على POST استخدمت طريقة الطلب إلى ملقم الأصل قبول الكيان المغلقة في طلب جديد المرؤوس من الموارد التي حددتها Request-URI في Request-Line

وبعبارة أخرى ، POST يستخدم إنشاء.

على PUT طريقة تطلب المغلقة كيان يتم تخزينها تحت الموردة Request-URI.إذا كان Request-URI يشير إلى القائمة بالفعل الموارد المغلقة الكيان ينبغي أن تعتبر نسخة معدلة من أحد المقيمين على ملقم الأصل.إذا كان Request-URI لا يشير إلى الموارد القائمة ، وأن اوري قادر على أن يعرف بأنه مورد جديد حسب طلب المستخدم عميل ملقم الأصل يمكن أن تخلق الموارد مع أن URI."

وهذا هو ، PUT يستخدم إنشاء أو تحديث.

لذا أي واحد يجب أن تستخدم لخلق الموارد ؟ أو واحد يحتاج إلى دعم على حد سواء ؟

Answer 1

عموما:

كل من وضع وظيفة يمكن استخدامها لخلق.

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

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

أنت لا تحتاج إلى دعم كل من وضع وآخر.

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

بعض الاعتبارات:

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

على سبيل المثال:

كتبت التالية كجزء من جواب آخر على ذلك بخصوص هذا:

وظيفة:

تستخدم لتعديل وتحديث الموارد

POST /questions/<existing_question> HTTP/1.1
Host: www.example.com/

علما بأن التالية خطأ:

POST /questions/<new_question> HTTP/1.1
Host: www.example.com/

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

على الرغم من أنك يمكن أن تفعل شيئا مثل هذا إلى إنشاء الموارد باستخدام وظيفة:

POST /questions HTTP/1.1
Host: www.example.com/

لاحظ أنه في هذه الحالة الموارد اسم لم يتم تحديد كائنات جديدة مسار URL سوف تعاد لك.

وضع:

تستخدم لإنشاء مورد ، أو الكتابة فوقه.في حين يمكنك تحديد الموارد URL الجديد.

عن مورد جديد:

PUT /questions/<new_question> HTTP/1.1
Host: www.example.com/

استبدال الموارد الحالية:

PUT /questions/<existing_question> HTTP/1.1
Host: www.example.com/

Answer 2

يمكنك أن تجد تأكيدات على شبكة الإنترنت أن أقول

• بعد ينبغي أن تستخدم لخلق الموارد ، وضع ينبغي أن تستخدم لتعديل واحد
• وضع ينبغي أن تستخدم لخلق الموارد ، بعد ينبغي أن تستخدم لتعديل واحد

لا هو على حق تماما.

---

الأفضل هو اختيار بين وضع وظيفة على أساس idempotence العمل.

وضع يعني وضع الموارد استبدال تماما كل ما هو متاح في عنوان URL معين مع شيء مختلف.بحكم التعريف ، هو وضع idempotent.القيام بذلك عدة مرات كما تريد ، و النتيجة هي نفسها. x=5 هو idempotent.يمكنك وضع الموارد سواء كان سابقا موجود أم لا (على سبيل المثال ، إنشاء أو تحديث)!

بعد التحديثات الموارد ، يضيف الفرعية الموارد ، أو يؤدي إلى تغيير.وظيفة ليست idempotent ، في الطريقة التي x++ لا idempotent.

---

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

لذلك:

POST /expense-report

أو:

PUT  /expense-report/10929

Answer 3

• بعد إلى URL يخلق الطفل الموارد في تعريف الخادم URL.
• وضع إلى URL يخلق/محل الموارد في مجملها في العميل المحددة URL.
• التصحيح إلى URL التحديثات جزء من الموارد في أن العميل تحديد عنوان URL.

المواصفات ذات الصلة من أجل وضع وظيفة RFC 2616 §9.5 ff.

آخر يخلق طفل الموارد, حتى بعد أن /items يخلق الموارد التي تعيش تحت /items الموارد.على سبيل المثال. /items/1.إرسال نفس المنصب حزم مرتين سيتم إنشاء اثنين من الموارد.

وضع هو إنشاء أو استبدال الموارد في URL معروفة من قبل العميل.

ولذلك: وضع هو فقط مرشحا خلق فيها العميل يعرف url قبل الموارد التي تم إنشاؤها.على سبيل المثال. /blogs/nigel/entry/when_to_use_post_vs_put كما في العنوان هو استخدام الموارد الرئيسية

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

RFC يقرأ مثل هذا:

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

ملاحظة: وضع معظمها تم استخدامها لتحديث الموارد (قبل استبدالها في entireties) ، ولكن في الآونة الأخيرة كانت هناك حركة نحو استخدام التصحيح تحديث الموارد المتاحة ، كما وضعت ينص على أنه يستبدل كل الموارد. RFC 5789.

تحديث 2018:هناك قضية يمكن أن يتم تجنب وضع.انظر "بقية دون وضع"

مع "بقية دون وضع" تقنية, الفكرة هي أن المستهلكين أجبر على المنصب الجديد 'nounified طلب الموارد.كما ناقش في وقت سابق, تغيير العميل العنوان البريدي POST جديد "ChangeOfAddress" الموارد لا تضع "العميل" الموارد مع مختلفة العنوان البريدي قيمة الحقل.

مأخوذة من بقية API تصميم الموارد النمذجة من خلال براكاش سوبرامانيام من Thoughtworks

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

Answer 4

موجز:

إنشاء:

لا يمكن أن يؤديها مع كل وضع أو نشر بالطريقة التالية:

وضع

يخلق على مورد جديد مع newResourceId كما المعرف تحت /الموارد URI ، أو جمع.

PUT /resources/<newResourceId> HTTP/1.1 

بعد

يخلق A مورد جديد تحت /الموارد URI ، أو جمع.عادة المعرف يتم إرجاعها من قبل الملقم.

POST /resources HTTP/1.1

تحديث:

يمكن فقط يتم وضعها بالطريقة التالية:

وضع

التحديثات الموارد مع existingResourceId كما المعرف تحت /الموارد URI ، أو جمع.

PUT /resources/<existingResourceId> HTTP/1.1

التفسير:

عند التعامل مع بقية URI العامة ، لديك عامة على اليسار و محددة على صحيح.على الأدوية وعادة ما تسمى مجموعات وأكثر محددة البنود يمكن أن يسمى الموارد.علما أن الموارد يمكن أن تحتوي على جمع.

أمثلة:

<-- عام -- محددة -->

URI: website.com/users/john
website.com  - whole site
users        - collection of users
john         - item of the collection, or a resource

URI:website.com/users/john/posts/23
website.com  - whole site
users        - collection of users
john         - item of the collection, or a resource
posts        - collection of posts from john
23           - post from john with identifier 23, also a resource

عند استخدام وظيفة أنت دائما يشير إلى جمع, لذا عندما تقول:

POST /users HTTP/1.1

تقوم بالإرسال مستخدم جديد إلى المستخدمين جمع.

إذا كنت تذهب على محاولة شيء من هذا القبيل:

POST /users/john HTTP/1.1

وسوف لغويا أنت تقول أنك تريد إضافة مورد إلى جون جمع تحت المستخدمين جمع.

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

PUT /users/john HTTP/1.1

أنت تقول أن الخادم أو تحديث أو إنشاء إذا لم يكن موجودا ، جون الموارد تحت المستخدمين جمع.

المواصفات:

اسمحوا لي أن أسلط الضوء على بعض أجزاء هامة من المواصفات:

بعد

على بعد يتم استخدام طريقة طلب أن الأصل الخادم تقبل الكيان المغلقة في الطلب كما جديد المرؤوس من الموارد التي حددها طلب-URI في طلب خط

ومن ثم يخلق جديد الموارد على جمع.

وضع

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

ومن ثم إنشاء أو تحديث على أساس وجود الموارد.

المرجع:

• HTTP/1.1 المواصفات
• ويكيبيديا - بقية
• الموارد الموحد معرفات (URI):عامة بناء الجملة ودلالات

Answer 5

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

لذلك:حفظ مستخدم موجود أو أحد حيث يقوم العميل بإنشاء معرف انه تم التحقق من أن الهوية هي فريدة من نوعها:

PUT /user/12345 HTTP/1.1  <-- create the user providing the id 12345
Host: mydomain.com

GET /user/12345 HTTP/1.1  <-- return that user
Host: mydomain.com

خلاف ذلك ، استخدم وظيفة في البداية إنشاء الكائن ، ووضع تحديث وجوه:

POST /user HTTP/1.1   <--- create the user, server returns 12345
Host: mydomain.com

PUT /user/12345 HTTP/1.1  <--- update the user
Host: mydomain.com

Answer 6

آخر يعني "إنشاء جديد" كما في "هنا هي المدخل إنشاء مستخدم إنشاء عني".

وضع يعني "إدراج محل إذا كان موجودا بالفعل" كما في "هنا هو بيانات المستخدم 5".

كنت آخر example.com/users منذ كنت لا تعرف عنوان المستخدم حتى الآن ، تريد الخادم إلى إنشاء.

كنت وضعت على example.com/users/id منذ كنت تريد استبدال/إنشاء محددة المستخدم.

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

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

Answer 7

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

PUT    /items/1      #=> update
POST   /items        #=> create

Answer 8

سواء تستخدم لنقل البيانات بين العميل إلى الخادم, ولكن هناك اختلافات بينهما،:

القياس:

• وضع أيتأخذ ، وضع حيث كان.
• منصب إرسال البريد في بعد مكتب.

وسائل الاعلام الاجتماعية/شبكة التشبيه:

• بعد على وسائل الاعلام الاجتماعية:عندما نقوم بنشر الرسالة ، فإنه يخلق وظيفة جديدة.
• وضع(أيتحرير) عن الرسالة التي نشرت بالفعل.

Answer 9

باقي هو جدا ارتفاع مستوى المفهوم.في الواقع, فإنه لا يذكر حتى HTTP على الإطلاق!

إذا كان لديك أي شكوك حول كيفية تنفيذ بقية في HTTP, يمكنك دائما أن تأخذ نظرة على ذرة نشر البروتوكول (AtomPub) المواصفات.AtomPub هو معيار للكتابة راحة webservices مع HTTP التي تم تطويرها من قبل العديد من HTTP و بقية النجوم ، مع بعض المدخلات من روي إيفاد مخترع الراحة (co-)مخترع HTTP نفسه.

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

هذا ما AtomPub عن خلق الموارد (المادة 9.2):

لإضافة أعضاء إلى مجموعة العملاء إرسال طلبات الوظائف إلى أوري المجموعة.

Answer 10

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

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

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

http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

فكرة راحة-URL هو في الحقيقة انتهاك بقية الملقم هو المسؤول عن بنية عنوان URL و يجب أن تكون حرة في أن تقرر كيفية استخدامها لتجنب الإزدواج.إذا كان هذا يخلط كنت اقرأ عن أهمية اكتشاف الذات على تصميم API.

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

1. العميل بنشر مورد جديد إلى الملقم.
2. الخادم بمعالجة الطلب ويرسل الرد.
3. العميل لا يتلقى استجابة.
4. الخادم هو علم العميل لم يتلق ردا.
5. العميل لا URL الموارد (لذلك وضعت ليس خيارا) ويكرر هذا المنصب.
6. المنصب ليس idempotent والخادم ...

الخطوة 6 حيث الناس عادة الحصول على الخلط حول ما يجب القيام به.ومع ذلك ، ليس هناك ما يدعو إلى إنشاء الهمجية من أجل حل هذه المسألة.بدلا من ذلك, HTTP يمكن استخدامها على النحو المحدد في RFC 2616 والخادم الردود:

10.4.10 409 الصراع

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

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

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

ردت مع رمز حالة من 409 الصراع هو الصحيح لأن اللجوء:

• إجراء آخر من البيانات التي لديه الهوية التي يطابق الموارد بالفعل في النظام هو "صراع مع الوضع الحالي من الموارد."
• منذ الجزء المهم هو العميل لفهم الملقم الموارد واتخاذ الإجراءات المناسبة.هذا هو "الوضع(s) حيث من المتوقع أن المستخدم قد تكون قادرة على حل الصراع وإعادة تقديم الطلب."
• الرد الذي يحتوي على URL من الموارد مع متضاربة ID المناسبة شروط مسبقة الموارد من شأنه أن يوفر "ما يكفي من المعلومات عن مستخدم أو عامل المستخدم لحل المشكلة" وهي حالة مثالية في RFC 2616.

تحديث استنادا إلى الإفراج عن RFC 7231 إلى محل 2616

RFC 7231 يهدف إلى استبدال 2616 في القسم 4.3.3 يصف اتبع ممكن رد بعد

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

الآن قد يكون من المغري أن يعود ببساطة 303 في حالة الوظائف المتكررة.بيد أن العكس هو الصحيح.العودة 303 معنى إلا إذا متعددة إنشاء طلبات (خلق موارد مختلفة) عودة نفس المحتوى.على سبيل المثال سيكون "شكرا لتقديم طلبك الرسالة" أن العميل لا تحتاج إلى إعادة تحميل كل مرة.RFC 7231 لا تزال تحتفظ في القسم 4.2.2 هذا المنصب لا يمكن idempotent وتستمر في الحفاظ على هذا المنصب ينبغي أن تستخدم من أجل خلق.

لمزيد من المعلومات حول هذا ، قراءة هذا المادة.

Answer 11

أنا أحب هذه النصيحة ، RFC 2616 تعريف وضع:

الفرق الأساسي بين آخر ووضع طلبات ينعكس في معنى مختلف الطلب-URI.URI في طلب POST تحدد الموارد التي من شأنها التعامل مع المغلقة الكيان.أن الموارد قد تكون البيانات-قبول عملية بوابة أخرى البروتوكول ، أو كيان منفصل أن يقبل الشروح.في المقابل, URI في طلب وضع تحدد كيان المرفقة مع الطلب -- وكيل المستخدم يعرف ما URI هو المقصود الملقم يجب أن لا محاولة لتطبيق طلب إلى بعض الموارد الأخرى.

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

أفسر هذا ، idempotency متطلبات وضع ، يعني:

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

Answer 12

باختصار:

وضع هو idempotent ، حيث موارد الدولة سوف تكون هي نفسها إذا كان نفس العملية يتم تنفيذها مرة واحدة أو عدة مرات.

بعد غير idempotent ، حيث موارد الدولة قد أصبحت مختلفة إذا كانت العملية نفذت عدة مرات بالمقارنة مع تنفيذ مرة واحدة.

قياسا مع استعلام قاعدة البيانات

وضع يمكنك التفكير مماثلة إلى "تحديث الطالب تعيين عنوان = "abc" where id="123";

بعد يمكنك التفكير في شيء مثل "تضاف إلى الطالب(الاسم والعنوان) القيم ("اي بي سي" ، "xyzzz");

رقم الطالب هو السيارات التي تم إنشاؤها.

مع أن نفس الاستعلام يتم تنفيذه عدة مرات أو مرة واحدة ، الطالب الجدول الدولة لا يزال هو نفسه.

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

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

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

Answer 13

وظيفة مثل نشر رسالة إلى علبة بريد أو نشر البريد الإلكتروني إلى عنوان البريد الإلكتروني في قائمة الانتظار.وضع مثل عند وضع كائن في حجيرة حفرة أو مكان على الرف (له عنوان معروف).

مع وظيفة أنت بالإرسال إلى عنوان الانتظار أو جمع.مع وضع أنت وضع عنوان البند.

وضع هو idempotent.يمكنك إرسال طلب 100 مرات فإنه لا يهم.المنصب ليس idempotent.إذا قمت بإرسال طلب 100 مرة, سوف تحصل على 100 رسائل البريد الإلكتروني أو 100 الرسائل في صندوق البريد.

قاعدة عامة:إذا كنت تعرف معرف أو اسم البند استخدام وضع.إذا كنت تريد معرف أو اسم العنصر المعين من قبل الطرف المتلقي ، استخدم وظيفة.

Answer 14

إجابة جديدة (الآن أن أفهم بقية الأفضل):

وضع هو مجرد بيان ما محتوى الخدمة ينبغي من الآن فصاعدا أن تجعل تمثيل الموارد المحددة من قبل العميل.بعد بيان ما محتوى الخدمة يجب من الآن فصاعدا تحتوي على (ربما تتكرر) لكنه يصل إلى الخادم كيفية التعرف على هذا المحتوى.

PUT x (إذا x يحدد الموارد):"استبدال المحتوى من الموارد التي حددتها x مع المحتوى الخاص بي."

PUT x (إذا x لا تحديد الموارد):"إنشاء مورد جديد يحتوي على المحتوى واستخدام x لتحديد ذلك."

POST x:"تخزين المحتوى الخاص بي وتعطيني معرف التي يمكن استخدامها لتحديد الموارد (قديمة أو جديدة) تحتوي على محتوى قال (ربما مختلطة مع غيرها من المحتوى).قال الموارد يجب أن تكون متطابقة أو المرؤوس الذي x يحدد." "y's الموارد هي تابعة x's الموارد" هو عادة ولكن ليس بالضرورة تنفيذها من خلال جعل y أ subpath من x (مثلا ، x = /foo و y = /foo/bar) وتعديل التمثيل(ق) من x's الموارد تعكس وجود موارد جديدة, على سبيل المثالمع ارتباط تشعبي إلى y's الموارد و بعض البيانات الوصفية.إلا أن هذا الأخير هو ضروري حقا أن التصميم الجيد ، عناوين مبهمة في بقية أنت من المفترض أن استخدام الوسائط الفائقة بدلا من العميل URL البناء لاجتياز الخدمة على أي حال.

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

الجواب الأصلية (قد يكون أسهل للقراءة):

PUT /something (إذا /something موجود بالفعل):"خذ ما لديك /something واستبدالها ما أعطي لك."

PUT /something (إذا /something لم يكن موجودا بالفعل):"خذ ما أعطيتك ووضعها في /something."

POST /something:"خذ ما أعطيتك ووضعها في أي مكان تريد تحت /something طالما أنك تعطيني رابط عند الانتهاء من ذلك."

Answer 15

الجواب القصير:

قاعدة بسيطة من الإبهام:استخدام وظيفة لإنشاء استخدام وضع التحديث.

الجواب طويل:

وظيفة:

• آخر يستخدم لإرسال البيانات إلى الخادم.
• مفيدة عندما مورد URL غير معروف

وضع:

• وضعت المستخدمة في نقل الدولة إلى الملقم
• مفيدة عند مورد عنوان URL هو معروف

أطول الجواب:

نحن بحاجة إلى السؤال لماذا وضعت ، ما هي المشاكل ووضع كان يحاول حل هذا المنصب لا.

من بقية العمارة وجهة نظر ليس من المسائل.يمكن أن عاشوا دون وضع كذلك.ولكن من عميل المطور وجهة نظر جعلت له/لها الحياة أبسط كثيرا.

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

Answer 16

روبي على القضبان 4.0 استخدام "تصحيح" الأسلوب بدلا من وضع تفعل التحديثات الجزئية.

RFC 5789 يقول عن التصحيح (منذ عام 1995):

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

"حافة القضبان:التصحيح هو جديد الابتدائي HTTP طريقة للحصول على التحديثات"ما يفسر ذلك.

Answer 17

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

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

Answer 18

في طريقة بسيطة جدا أنا أخذ مثال على Facebook الزمني.

حالة 1:عندما تنشر شيئا على الجدول الزمني الخاص بك, انها دخولا جديدا.حتى في هذه الحالة أنها تستخدم أسلوب آخر لأن أسلوب آخر غير idempotent.

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

الحالة 3:إذا كان صديقك التعديلات تعليق له ، في هذه الحالة ، كان لديهم تعليق id, بحيث سيتم تحديث القائمة التعليق بدلا من إنشاء إدخال جديد في قاعدة البيانات.ولذلك هذا النوع من عملية استخدام أسلوب وضع لأنها idempotent.*

في خط واحد ، استخدام بعد لإضافة إدخال جديد في قاعدة البيانات وضع إلى التحديث شيء في قاعدة البيانات.

Answer 19

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

على سبيل المثال, قد لا يكون فكرة جيدة لإنشاء معاملات بطاقات الائتمان مع المنصب.

إذا كنت يحدث لديها السيارات ولدت URI على الموارد الخاصة بك لا يزال يمكنك استخدام وضع طريق تمرير ولدت URI (مشيرا إلى فارغة الموارد) إلى العميل.

بعض الاعتبارات الأخرى:

• آخر يبطل مؤقتا نسخة كاملة تحتوي على الموارد (أفضل الاتساق)
• وضع ردود ليست cacheable بينما وظيفة منها (تتطلب محتوى الموقع و انتهاء الصلاحية)
• وضع أقل تدعمها مثلاجافا لي ، المتصفحات القديمة, الجدران النارية

Answer 20

يبدو أن هناك دائما بعض التباس عند استخدام HTTP POST مقابل HTTP أسلوب وضع بقية الخدمات.معظم المطورين سوف محاولة لربط عمليات الخام مباشرة إلى أساليب HTTP.سوف يقولون أن هذا غير صحيح و لا يمكن للمرء ببساطة ربط الخام المفاهيم HTTP الأساليب.وهذا هو:

Create => HTTP PUT
Retrieve => HTTP GET
Update => HTTP POST
Delete => HTTP DELETE

صحيح أن R(etrieve) و د(elete) من عمليات الخام يمكن تعيينها مباشرة إلى أساليب HTTP الحصول وحذف على التوالي.لكن الخلط يكمن في ج(اء) و U(تحديث) العمليات.في بعض الحالات, يمكن للمرء أن استخدام وضع من أجل إنشاء بينما في حالات أخرى بعد سوف تكون مطلوبة.الغموض يكمن في تعريف HTTP وضع طريقة مقابل HTTP الأسلوب POST.

وفقا HTTP 1.1 المواصفات الحصول على, رأس, حذف, ووضع الأساليب يجب أن تكون idempotent بعد الطريقة ليست idempotent.وهذا يعني أن العملية idempotent إذا كان لا يمكن أن يؤديها على الموارد مرة واحدة أو مرات عديدة العودة دائما نفس الدولة من الموارد.في حين أن غير idempotent العملية يمكن العودة تعديل حالة الموارد من طلب واحد إلى آخر.وبالتالي في عدم idempotent العملية ، ليس هناك ما يضمن أن أحدا لن يحصل على نفس الدولة من الموارد.

بناء على ما سبق idempotent تعريف بلدي يأخذ على استخدام HTTP وضع طريقة مقابل باستخدام HTTP POST طريقة بقية الخدمات:استخدام HTTP وضع الطريقة عندما:

The client includes all aspect of the resource including the unique identifier to uniquely identify the resource. Example: creating a new employee.
The client provides all the information for a resource to be able to modify that resource.This implies that the server side does not update any aspect of the resource (such as an update date).

في كلتا الحالتين هذه العمليات يمكن القيام بها عدة مرات مع نفس النتائج.هذا هو المورد لا يمكن تغييرها من قبل الطالبة العملية أكثر من مرة.وبالتالي الحقيقية idempotent العملية.استخدام أسلوب HTTP POST عندما:

The server will provide some information concerning the newly created resource. For example, take a logging system. A new entry in the log will most likely have a numbering scheme which is determined on the server side. Upon creating a new log entry, the new sequence number will be determined by the server and not by the client.
On a modification of a resource, the server will provide such information as a resource state or an update date. Again in this case not all information was provided by the client and the resource will be changing from one modification request to the next. Hence a non idempotent operation.

الختام

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

Answer 21

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

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

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

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

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

سوف بسرعة بقعة التشابه مع وعود:ونحن إنشاء وإعادة نائبا النتيجة قبل القيام بأي شيء.كما وعد إجراء يمكن أن تنجح أو تفشل مرة واحدة, ولكن يمكن أن تكون النتيجة المنال مرارا وتكرارا.

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

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

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

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

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

Answer 22

ملقم الأصل يمكن أن تخلق الموارد مع أن URI

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

كما اقتبس المذكورة ، يمكنك استخدام وضع لإنشاء لا يوجد الموارد المخصصة إلى IRI و تريد إنشاء الموارد على أي حال.على سبيل المثال ، PUT /users/123/password عادة ما يستبدل كلمة المرور القديمة بأخرى جديدة ، ولكن يمكنك استخدامه لإنشاء كلمة المرور إذا لم تكن موجودة بالفعل (على سبيل المثال ، عن طريق حديثا للمستخدمين المسجلين أو من خلال استعادة حظر المستخدمين).

Answer 23

بالإضافة إلى الخلافات المقترحة من قبل الآخرين ، أريد أن أضيف أكثر من ذلك.

في بعد طريقة يمكنك ارسال الجسم params في form-data

في وضع الطريقة عليك أن ترسل الجسم params في x-www-form-urlencoded

رأس Content-Type:application/x-www-form-urlencoded

وفقا لهذا لا يمكن إرسال الملفات أو البيانات متعددة في وضع طريقة

تحرير

نوع المحتوى "application/x-www-form-urlencoded" غير فعالة إرسال كميات كبيرة من البيانات الثنائية أو نص يحتوي على أحرف غير ASCII.نوع المحتوى "multipart/form-data" يجب أن يكون استخدام الاستمارات التي تحتوي على ملفات غير ASCII البيانات ، البيانات الثنائية.

مما يعني إذا كان عليك أن تقدم

الملفات غير ASCII البيانات ، البيانات الثنائية

يجب عليك استخدام بعد طريقة

Answer 24

أنا ذاهب إلى الأراضي التالية:

وضع يشير إلى الموارد التي حددتها URI.في هذه الحالة ، يتم تحديثه.هو جزء من الأفعال الثلاثة مشيرا إلى الموارد-حذف والحصول على كونها اثنين آخرين.

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

---

لأنه وضع على القائمة الرجوع إلى الموارد ، فهي أيضا من خلال تعريف idempotent.

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

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

---

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

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

Answer 25

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

سأذكر الاتفاقيات التي أعتقد هي الأكثر استخداما و الأكثر المفيدة:

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

عند الرد على الموارد في عنوان URL معين ، وغالبا ما يتم نشر ذات الصلة قطعة من المعلومات إلى عنوان URL هذا.وهذا يعني أن الموارد في URL موجود بالفعل.

على سبيل المثال, عندما كنت ترغب في إنشاء تيار جديد ، يمكنك وضعه إلى بعض عناوين URL.ولكن عندما تريد إرسال رسالة إلى القائمة تيار آخر إلى عنوان URL الخاص به.

كما لتعديل خصائص تيار ، يمكنك أن تفعل ذلك مع أي وضع أو آخر.في الأساس, فقط استخدام "وضع" عندما تكون العملية idempotent - على خلاف ذلك استخدام المنصب.

نلاحظ أن ليس جميع المتصفحات الحديثة دعم HTTP الأفعال الأخرى من الحصول على أو آخر.

Answer 26

معظم الوقت سوف تستخدمها مثل هذا:

• بعد مورد إلى مجموعة
• وضع الموارد التي تم تحديدها من قبل مجموعة/:id

على سبيل المثال:

• بعد /البنود
• وضع /البنود/1234

في كلتا الحالتين, طلب الجسم يحتوي على بيانات عن الموارد التي سيتم إنشاؤها أو تحديثها.فإنه ينبغي أن يكون واضحا من الأسماء الطريق هذا المنصب ليس idempotent (إذا كنت اسميها 3 مرات فإنه سيتم إنشاء 3 الأجسام) ، ولكن وضع هو idempotent (إذا كنت اسميها 3 مرات والنتيجة هي نفسها).وضعت غالبا ما يستخدم "upsert" عملية (إنشاء أو تحديث) ولكن يمكنك دائما العودة 404 إذا كنت تريد فقط إلى تعديل.

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

تذكر بقية مجموعة من الاتفاقيات و المبادئ التوجيهية للحفاظ على API بسيطة.إذا كنت في نهاية المطاف مع عمل معقدة حول فقط إلى التحقق من "مريحة" المربع ثم أنت هزيمة الغرض؛)

Answer 27

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

دعونا نكون واضحين جدا و مباشر من هنا.إذا كنت .NET developer العمل مع API ويب, الحقائق (من API مايكروسوفت وثائق) ، http://www.asp.net/web-api/overview/creating-web-apis/creating-a-web-api-that-supports-crud-operations:

1. PUT = UPDATE (/api/products/id)
2. MCSD Exams 2014 -  UPDATE = PUT, there are **NO** multiple answers for that question period.

متأكد من أنك "أن" استخدام "بوست" إلى تحديث ، ولكن فقط اتبع الاتفاقيات وضعت لك مع إعطاء الإطار.في حالتي هو .NET / Web API, لذلك وضع هو التحديث لا يوجد المناقشة.

آمل أن يساعد هذا أي مطوري Microsoft أن قرأت كل التعليقات مع أمازون و الشمس/Java وصلات الانترنت.

Answer 28

إذا كنت معتادا على قاعدة بيانات العمليات ، هناك

1. حدد
2. إدراج
3. التحديث
4. حذف
5. دمج (التحديث إذا الموجودة بالفعل, آخر إدراج)

يمكنني استخدام PUT دمج وتحديث مثل عمليات استخدام POST على الإدراج.

Answer 29

وهنا قاعدة بسيطة:

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

بعد إلى URL ينبغي أن تستخدم لتحديث أو إنشاء الموارد التي تقع في بعض الدول الأخرى ("تابعة") URL أو لا locatable عبر HTTP.

Answer 30

في الممارسة, آخر يعمل بشكل جيد لخلق الموارد.URL التي تم إنشاؤها حديثا الموارد يجب أن تعاد في موقع رأس استجابة.وضعت ينبغي أن تستخدم من أجل تحديث مورد تماما.يرجى نفهم أن هذه هي أفضل الممارسات عند تصميم API مريحة.HTTP مواصفات هذا النحو لا يقيد استخدام وضع/آخر مع عدد قليل من القيود المفروضة على إنشاء/تحديث الموارد.نلقي نظرة على http://techoctave.com/c7/posts/71-twitter-rest-api-dissected الذي يلخص أفضل الممارسات.