it-swarm.asia

ضع مقابل POST في REST

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

تُستخدم الطريقةPOSTللمطالبة بقبول خادم Origin الكيان المدرج في الطلب كمرؤوس جديد للمورد المحدد بواسطة Request-URI في Request-Line

بمعنى آخر ، POST يُستخدم في create .

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

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

لذلك ، أي واحد ينبغي أن تستخدم لإنشاء مورد؟ أو يحتاج المرء لدعم كليهما؟

4925
alex

بشكل عام:

يمكن استخدام كل من PUT و POST لإنشاء.

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

يمكن استخدام كلاهما عظيمًا ، لذا يجب استخدام أي منهما في تصميمي المريح:

لا تحتاج إلى دعم كل من PUT و POST.

الذي يستخدم ويترك لك. لكن تذكر فقط استخدام العنصر المناسب بناءً على الشيء الذي تشير إليه في الطلب.

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

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

مثال:

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

وظيفة:

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

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

لاحظ أن ما يلي خطأ:

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

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

على الرغم من ذلك يمكنك القيام بشيء كهذا لإنشاء موارد باستخدام POST:

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/
3880
Brian R. Bondy

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

لا هو الصحيح تماما.


الأفضل هو الاختيار بين PUT و POST بناءً على العاطفة للعمل.

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

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


من خلال هذه الوسيطة ، يكون PUT مخصصًا عند معرفة عنوان URL الخاص بالشيء الذي ستقوم بإنشائه. POST يمكن استخدامها لإنشاء عندما تعرف عنوان URL الخاص بـ "المصنع" أو المدير لفئة الأشياء التي ترغب في إنشائها.

وبالتالي:

POST /expense-report

أو:

PUT  /expense-report/10929
2053
Cheeso
  • نشرإلى عنوان URL يقوم بإنشاء مورد فرعي عند تعريف الخادم URL.
  • PUTإلى عنوان URL يقوم بإنشاء/استبدال المورد بكامله في تعريف العميل URL.
  • PATCHلعنوان URL تحديثات جزء للمورد على عنوان URL المحدد لذلك العميل.

المواصفات ذات الصلة لـ PUT و POST هي RFC 2616 §9.5ff.

POST تنشئ موردًا تابعًا ، لذلك POST إلى /items تنشئ موردًا يعيش تحت مورد /items. على سبيل المثال. /items/1. يؤدي إرسال حزمة النشر نفسها مرتين إلى إنشاء مصدرين.

PUTمخصص لإنشاء أو استبدال مورد على عنوان URL معروف من قبل العميل .

لذلك:PUTليست سوى مرشح لـ CREATE حيث يعرف العميل بالفعل عنوان url قبل إنشاء المورد. على سبيل المثال. /blogs/nigel/entry/when_to_use_post_vs_put حيث يتم استخدام العنوان كمفتاح مورد

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

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

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

ملاحظة: تم استخدام PUT في الغالب لتحديث الموارد (عن طريق استبدالها بكليتها) ، ولكن هناك مؤخرًا حركة نحو استخدام PATCH لتحديث الموارد الحالية ، حيث يحدد PUT أنه يحل محل المورد بأكمله. RFC 5789.

التحديث 2018 : هناك حالة يمكن إجراؤها لتجنب PUT. انظر "الراحة دون وضع"

مع تقنية "REST without PUT" ، الفكرة هي أن المستهلكين يجبرون على نشر موارد طلب "غير مسمى" جديدة. كما نوقش سابقًا ، فإن تغيير العنوان البريدي للعميل هو POST إلى مورد "ChangeOfAddress" جديد ، وليس وضع مورد "عميل" بقيمة حقل حقل بريدية مختلفة.

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

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

642
Nigel Thorne

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

لذلك: لحفظ مستخدم حالي ، أو مستخدم ينشئ فيه العميل المعرف ، وتم التحقق من أن المعرف فريد من نوعه:

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 لإنشاء الكائن في البداية ، ثم ضعه لتحديث الكائن:

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
169
ThaDon

POST تعني "إنشاء جديد" كما في "هنا هو الإدخال لإنشاء مستخدم ، إنشاءه بالنسبة لي".

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

أنت POST إلى example.com/users لأنك لا تعرف عنوان URL الخاص بالمستخدم حتى الآن ، فأنت تريد أن يقوم الخادم بإنشائه.

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

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

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

162
Alexander Torstling

استخدم POST لإنشاء و PUT للتحديث. هكذا يفعل روبي أون ريلز ، على أي حال.

PUT    /items/1      #=> update
POST   /items        #=> create
121
Tim Sullivan

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

 Enter image description here

القياس:

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

 enter image description here

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

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

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

إذا كانت لديك أي شكوك حول كيفية تنفيذ REST في HTTP ، فيمكنك دائمًا إلقاء نظرة على Atom Publication Protocol (AtomPub) specification. يعد AtomPub معيارًا لكتابة خدمات RESTful على الويب باستخدام HTTP والتي تم تطويرها بواسطة العديد من HTTP و REST النجوم ، مع بعض المدخلات من Roy Fielding ، مخترع REST و (مشارك) مخترع HTTP نفسه.

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

هذا ما يقوله AtomPub حول إنشاء الموارد (القسم 9.2):

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

65
Jörg W Mittag

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

في هذه المرحلة ، سوف يجادل بعض الأشخاص بأنه إذا تم استخدام {RESTful-URL's} ، فإن العميل يعرف عنوان URL للمورد وبالتالي فإن PUT مقبول. بعد كل هذا ، هذا هو السبب وراء أهمية عناوين URL الكندية والمطابقة وروبي أون ريلز وعناوين جانغو وإلقاء نظرة على واجهة برمجة تطبيقات تويتر ... بلاه بلاه بلاه. يحتاج هؤلاء الأشخاص إلى فهم لا يوجد شيء اسمه URL مريح وهذا يقول روي فيلدنج نفسه :

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

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

فكرة (RESTful-URL هي في الواقع انتهاك لـ REST لأن الخادم مسؤول عن بنية عنوان URL ويجب أن يكون حرا في تقرير كيفية استخدامه لتجنب الاقتران. إذا كان هذا يخلط بينك وبين قراءة أهمية اكتشاف الذات في تصميم واجهة برمجة التطبيقات.

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

  1. العميل POST مورد جديد للخادم.
  2. يقوم الخادم بمعالجة الطلب وإرسال استجابة.
  3. لا يتلقى العميل الاستجابة أبدًا.
  4. الخادم غير مدرك أن العميل لم يتلق الاستجابة.
  5. ليس لدى العميل عنوان URL للمورد (وبالتالي PUT ليس خيارًا) ويكرر POST.
  6. POST ليس idempotent والخادم ...

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

10.4.10 409 الصراع

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

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

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

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

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

تحديث يستند إلى إصدار RFC 7231 إلى استبدال 2616

RFC 7231 تم تصميمه ليحل محل 2616 وفي القسم 4.3.3 يصف الاستجابة الممكنة التالية لـ POST

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

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

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

58
Joshcodes

أحب هذه النصيحة ، من تعريف RFC 2616 لـ PUT :

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

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

أفسر هذا ، ومتطلبات العاطفة على PUT ، ليعني ذلك:

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

بالمختصر:

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

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

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

PUTيمكنك التفكير في تشبه عنوان "UPDATE STUDENT SET address =" abc "حيث id =" 123 "؛

POSTيمكنك التفكير في شيء مثل "INSERT INTO STUDENT (الاسم ، العنوان) VALUES (" abc "،" xyzzz ") ؛

يتم إنشاء معرف الطالب تلقائيًا.

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

في حالة اختبار POST ، إذا تم تنفيذ نفس الاستعلام عدة مرات ، يتم إنشاء سجلات طالب متعددة في قاعدة البيانات وتتغير حالة قاعدة البيانات على كل تنفيذ لاستعلام "INSERT".

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

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

45
bharatj

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

مع POST ، تقوم بالنشر إلى عنوان QUEUE أو COLLECTION. مع PUT ، فأنت تضع عنوان العنصر.

PUT غير شغوف. يمكنك إرسال الطلب 100 مرة ولن يهم. POST ليست عاطفية. إذا قمت بإرسال الطلب 100 مرة ، فستحصل على 100 رسالة بريد إلكتروني أو 100 رسالة في صندوقك البريدي.

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

POST versus PUT

42
Homer6

إجابة جديدة (الآن بعد أن فهمت REST بشكل أفضل):

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

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

PUT x (إذا لم يعرّف x موردًا): "قم بإنشاء مورد جديد يحتوي على المحتوى الخاص بي واستخدم x لتحديده."

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

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

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

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

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

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

38
Jordan

اجابة قصيرة:

قاعدة بسيطة للإبهام: استخدم POST لإنشاء ، استخدم PUT للتحديث.

اجابة طويلة:

بريد:

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

ضع:

  • يستخدم PUT لنقل الحالة إلى الخادم
  • مفيد عندما يكون عنوان URL للمورد معروفًا

الإجابة الأطول:

لفهمها ، يجب أن نتساءل عن سبب طلب PUT ، ما هي المشكلات التي كان يحاول PUT حلها POST لم يستطع.

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

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

36
ishandutta2007

سيستخدم Ruby on Rails 4.0 طريقة "PATCH" بدلاً من PUT لإجراء تحديثات جزئية.

يقول RFC 5789 عن PATCH (منذ 1995):

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

" Edge Rails: PATCH هي طريقة HTTP الأساسية الجديدة للتحديثات " توضح ذلك.

35
germanlinux

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

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

26
skillet-thief

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

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

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

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

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

21
UniCoder

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

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

إذا صادفت أن يكون لديك عنوان URI تم إنشاؤه تلقائيًا على موردك ، فلا يزال بإمكانك استخدام PUT بتمرير URI تم إنشاؤه (يشير إلى مورد فارغ) إلى العميل.

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

  • POST يبطل النسخ المخبأة من المورد الذي يحتوي على كامل (تناسق أفضل)
  • استجابات PUT غير قابلة للتخزين المؤقت بينما POST الردود (تتطلب محتوى الموقع وانتهاء الصلاحية)
  • PUT أقل دعمًا على سبيل المثال Java ME والمتصفحات القديمة والجدران النارية
20
Hans Malherbe

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

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

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

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

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

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

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

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

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

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

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

14
bbsimonbb

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

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

صحيح أنه يمكن تعيين R(etrieve) و D(elete) لعمليات CRUD مباشرة إلى أساليب HTTP GET و DELETE على التوالي. ومع ذلك ، يكمن الارتباك في عمليتي C(reate) و U(update). في بعض الحالات ، يمكن للمرء استخدام PUT لإنشاء ، بينما في حالات أخرى ستكون هناك حاجة POST. يكمن الغموض في تعريف طريقة HTTP PUT مقابل طريقة HTTP POST.

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

استنادًا إلى تعريف idempotent أعلاه ، فإن استخدامي لـ HTTP PUT مقابل استخدام الأسلوب HTTP POST لخدمات REST هو: استخدم أسلوب HTTP PUT عندما:

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).

في كلتا الحالتين ، يمكن إجراء هذه العمليات عدة مرات بنفس النتائج. هذا هو المورد لن يتم تغييره عن طريق طلب العملية أكثر من مرة. وبالتالي ، عملية حقيقية العاطفي. استخدم طريقة 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.

استنتاج

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

14
Burhan

يمكن لخادم الأصل إنشاء المورد باستخدام URI

إذن أنت تستخدم POST وربما ، ولكن ليس من الضروري PUT لإنشاء الموارد. ليس لديك لدعم كلا. بالنسبة لي POST يكفي تمامًا. لذلك هو قرار التصميم.

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

13
inf3rno

انا ذاهب الى الهبوط مع ما يلي:

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

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


نظرًا لأن PUT و GET و DELETE يشيران إلى مورد ، فإنهما أيضًا بحكم تعريفهما.

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

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


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

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

11
Gerard ONeill

بالإضافة إلى الاختلافات التي اقترحها الآخرون ، أريد إضافة واحدة أخرى.

فيPOSTطريقة يمكنك إرسال بارامترات الجسم في form-data

فيوضعالطريقة التي يجب أن ترسلها في نص x-www-form-urlencoded

العنوان Content-Type:application/x-www-form-urlencoded

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

تصحيح

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

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

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

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

11
Rohit Dhiman

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

سوف أصف الاتفاقيات التي أعتقد أنها تستخدم على نطاق واسع وهي مفيدة للغاية:

عندما تضع موردًا في عنوان URL معين ، فإن ما يحدث هو أنه يجب حفظه على عنوان URL هذا أو أي شيء على هذا المنوال.

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

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

بالنسبة لتعديل خصائص الدفق ، يمكنك القيام بذلك إما باستخدام PUT أو POST. في الأساس ، استخدم فقط "PUT" عندما تكون العملية غير مناسبة - وإلا استخدم POST.

لاحظ ، مع ذلك ، أن جميع المتصفحات الحديثة لا تدعم أفعال HTTP بخلاف GET أو POST.

9
Gregory Magarshak

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

  • نشرمورد في مجموعة
  • PUTمورد تم تحديده بواسطة المجموعة /: id

فمثلا:

  • نشر/ العناصر
  • وضع/ items/1234

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

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

تذكر أن REST عبارة عن مجموعة من الاتفاقيات والإرشادات للحفاظ على واجهة برمجة التطبيقات بسيطة. إذا انتهى بك الأمر في حل بديل معقد لمجرد تحديد مربع "RESTfull" فإنك تهزم الهدف ؛)

7
tothemario

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

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

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

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

آمل أن يساعد هذا أي مطوري Microsoft يقرأ كل التعليقات باستخدام ارتباطات موقع Amazon و Sun/Java.

7
Tom Stickel

إليك قاعدة بسيطة:

PUTإلى عنوان URL يجب أن يستخدم لتحديث أو إنشاء المورد الذي يمكن أن يكون موجودًا على عنوان URL هذا.

يجب استخدامنشرإلى عنوان URL لتحديث أو إنشاء مورد موجود في عنوان URL آخر ("تابع") ، أو لا يمكن تحديد موقعه عبر HTTP.

6
Adam Griffiths

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

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

يمكنني استخدام PUT لدمج وتحديث مثل العمليات واستخدام POST لـ Insertions.

6
Rajan

في الممارسة العملية ، POST تعمل بشكل جيد لإنشاء الموارد. يجب إرجاع عنوان URL للمورد الذي تم إنشاؤه حديثًا في رأس استجابة الموقع. يجب استخدام PUT لتحديث مورد بالكامل. يرجى فهم أن هذه هي أفضل الممارسات عند تصميم واجهة برمجة تطبيقات RESTful. مواصفات HTTP على هذا النحو لا تقيد استخدام PUT/POST مع بعض القيود لإنشاء/تحديث الموارد. ألقِ نظرة على http://techoctave.com/c7/posts/71-Twitter-rest-api-dissected التي تلخص أفضل الممارسات.

5
java_geek

POST: استخدامه لإنشاء موارد جديدة. يشبه INSERT (عبارة SQL) مع معرف زيادة تلقائية. في جزء الاستجابة يحتوي على معرف جديد تم إنشاؤه.

يستخدم POST أيضًا لتحديث السجل.

ضع: استخدمه لإنشاء مورد جديد ، لكنني هنا أعرف مفتاح الهوية. يشبه INSERT (عبارة SQL) حيث أعرف مسبقًا مفتاح الهوية. في جزء الاستجابة لا يرسل شيئًا.

يستخدم PUT أيضًا لتحديث مورد

3
sushil pandey

لذلك ، أي واحد ينبغي أن تستخدم لإنشاء مورد؟ أو يحتاج المرء لدعم كليهما؟

يجب عليك استخدام PATCH. يمكنك تصحيح قائمة الأسئلة مثل

PATCH /questions HTTP/1.1

مع قائمة تحتوي على كائن ليتم إنشاؤه مثل

[
    {
        "title": "I said semantics!",
        "content": "Is this serious?",
        "answer": "Not really"
    }
]

انها طلب التصحيح كما

  • يمكنك تعديل القائمة قائمة الموارد دون توفير الجديد بالكامل المحتوى
  • قمت بتغيير حالة سؤالك الجديد من غير موجود إلى موجود دون تقديم جميع البيانات (سيرسل الخادم على الأرجح id).

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

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

العيب هو أنه ربما لا أحد يستخدم PATCH بهذه الطريقة. أخشى ، لقد اخترعت هذا الأمر ، لكنني آمل ، قدمت حجة جيدة.

يمكنك استخدام CREATE بدلاً من ذلك ، نظرًا لأن أفعال HTTP المخصصة مسموح بها ، فهي قد لا تعمل مع بعض الأدوات.

فيما يتعلق بالدلالات ، CREATE هو IMHO هو الخيار الصحيح الوحيد ، كل شيء آخر هو ربط مربوط في حفرة مستديرة. لسوء الحظ ، كل ما لدينا ثقوب مستديرة.

2
maaartinus