عمليات النمذجة في خدمة REST

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

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

POST api/member/john.smith/disable

لقد قرأت حلاً لقبول موردًا يمثل طلب تعطيل أحد الأعضاء ، كما هو موضح أدناه

public class DisableMemberRequest
{
    public string Username {get; set;}
}

ثم POST على المورد أعلاه

POST api/DisableMemberRequest

على الرغم من أن هذا النهج يبدو معقولًا ، إلا أنني أشعر أن هذا ليس صحيحًا من حيث واجهات واجهة برمجة التطبيقات النظيفة. يمكن أن يكون الأمر قابلاً للنقاش سواء كانت استجابة الطلب أعلاه يجب أن تكون 200 OK أو 201 Created أو 202 Accepted .

أفكر ، أود أن أضع موردًا جديدًا يسمى DisabledMember و PUT على هذا المورد يعني أنه يجب تعطيل عضو معين على النحو التالي

PUT api/disabledmember/john.smith

يبدو هذا تصميمًا صالحًا تمامًا من منظور REST/HTTP بالنسبة إلي. لكنني لست خبيراً وأرغب في التحقق من صحة ذلك مع الأشخاص الذين كانوا يفعلون ذلك لوقت طويل.

تصحيح

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

7

9 إجابة

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

POST /api/DisabledMembers
Content-Type: text/uri-list

http://example.org/api/members/john.smith

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

POST /api/ActiveMembers
Content-Type: text/uri-list

http://example.org/api/members/john.smith

هذا النهج له فائدة من حقيقة أن القيام GET/api/DisabledMembers سيكون أمرا طبيعيا تماما للقيام به. أيضا ، باستخدام text/uri-list يصبح من السهل تعطيل/إعادة تنشيط مجموعة من الأعضاء جميعا في نفس الوقت.

4
وأضاف
دعني أحصل على هذا الحق. هل تقترح أن PUT يوصى باستخدام بعض الحمولة بينما POST لا بأس بها بدون حمولة؟ أنا لست واضحا جدا في هذا الجانب. هل هناك أي مقالة/مدونة تتحدث أكثر عن هذا الجانب؟
وأضاف المؤلف Suhas, مصدر
السبب في استخدام PUT هو أن معرف المورد الذي سيتم إنشاؤه عند معالجة هذا الطلب معروف للعميل ، أو بعبارة أخرى أنت PUT ting on a known URL. عادة ما يتم استخدام POST عندما لا يعرف العميل عنوان URL للمورد الذي سيتم إنشاؤه.
وأضاف المؤلف Suhas, مصدر
وهو مشابه لما أخطط للقيام به. الاختلاف الوحيد هو استخدام POST بدلاً من PUT
وأضاف المؤلف Suhas, مصدر
Suhas ما نوع الوسائط التي سوف تضعها؟ أفترض أنه يمكنك PUT مع نص فارغ و DELETE لإعادة تنشيط.
وأضاف المؤلف Darrel Miller, مصدر
Suhas كلاهما غير شائع إلى حد ما. ومع ذلك ، بقدر ما أعرف أن المواصفات HTTP لا يوجد لديه اعتراض على أي منهما.
وأضاف المؤلف Darrel Miller, مصدر
suhas PUT صالحة تماما. كما ذكر ، من السهل بناء uri مقدما ، وهو عديم القيمة. لذلك ، PUT هو أكثر تمثيلا للدلالة. الشيء الغريب الوحيد هو عادة مع PUT أنت تضع شيئا تريد تخزينه. في حالتك ، فإن الإجراء الخاص بـ PUT هو ما هو مهم. ليس هناك حاجة حقاً إلى حمولة.
وأضاف المؤلف Darrel Miller, مصدر

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

POST /api/DisabledMembers
Content-Type: text/uri-list

http://example.org/api/members/john.smith

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

POST /api/ActiveMembers
Content-Type: text/uri-list

http://example.org/api/members/john.smith

هذا النهج له فائدة من حقيقة أن القيام GET/api/DisabledMembers سيكون أمرا طبيعيا تماما للقيام به. أيضا ، باستخدام text/uri-list يصبح من السهل تعطيل/إعادة تنشيط مجموعة من الأعضاء جميعا في نفس الوقت.

4
وأضاف
دعني أحصل على هذا الحق. هل تقترح أن PUT يوصى باستخدام بعض الحمولة بينما POST لا بأس بها بدون حمولة؟ أنا لست واضحا جدا في هذا الجانب. هل هناك أي مقالة/مدونة تتحدث أكثر عن هذا الجانب؟
وأضاف المؤلف Suhas, مصدر
السبب في استخدام PUT هو أن معرف المورد الذي سيتم إنشاؤه عند معالجة هذا الطلب معروف للعميل ، أو بعبارة أخرى أنت PUT ting on a known URL. عادة ما يتم استخدام POST عندما لا يعرف العميل عنوان URL للمورد الذي سيتم إنشاؤه.
وأضاف المؤلف Suhas, مصدر
وهو مشابه لما أخطط للقيام به. الاختلاف الوحيد هو استخدام POST بدلاً من PUT
وأضاف المؤلف Suhas, مصدر
Suhas كلاهما غير شائع إلى حد ما. ومع ذلك ، بقدر ما أعرف أن المواصفات HTTP لا يوجد لديه اعتراض على أي منهما.
وأضاف المؤلف Darrel Miller, مصدر
suhas PUT صالحة تماما. كما ذكر ، من السهل بناء uri مقدما ، وهو عديم القيمة. لذلك ، PUT هو أكثر تمثيلا للدلالة. الشيء الغريب الوحيد هو عادة مع PUT أنت تضع شيئا تريد تخزينه. في حالتك ، فإن الإجراء الخاص بـ PUT هو ما هو مهم. ليس هناك حاجة حقاً إلى حمولة.
وأضاف المؤلف Darrel Miller, مصدر
Suhas ما نوع الوسائط التي سوف تضعها؟ أفترض أنه يمكنك PUT مع نص فارغ و DELETE لإعادة تنشيط.
وأضاف المؤلف Darrel Miller, مصدر

الاقتراحات الأولى والثانية على حد سواء رائحة قليلا ، لأن لديهم فعل في URL. تحدد بنية RESTful الجيدة الموارد المشابهة للاسم فقط ، حيث يحدد بروتوكول HTTP مجموعة الأفعال القابلة للتطبيق على هذه الموارد.

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

من ما تقوله ، هناك عملية مهمة لتمكين أو تعطيل حساب المستخدم وعدم ارتياحك لكونه PUT أو PATCH ببساطة " "قيمة من true إلى false . إذا كان هذا يستغرق بعض الوقت ، ولديه حالة عابرة ، ومن المحتمل أن يكون شيئًا تريد أن تكون قادرًا على فضحه لمستخدمي واجهة برمجة التطبيقات حتى يكونوا على دراية بالعملية ، فمن المنطقي تحديد العملية نفسها كنوع من الموارد:

بدء التعطيل:

POST api/members/deactivations

الحصول على الحالة الحالية لإلغاء أو الإبلاغ عن الأنشطة التي حدثت:

GET api/members/deactivations/john.smith

إلغاء إلغاء التنشيط (اختياري):

DELETE api/members/deactivations/john.smith

إذا كان بإمكانك إعادة تنشيط حساب ، فقد يتبع ذلك نمطًا مماثلاً.

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

3
وأضاف
الفرق هو أن التعطيل هو بوضوح "شيء" يمكنك فهمه بشكل مستقل عن الموارد الأخرى ، ولكن لا يزال مرتبطًا بشدة بـ الأعضاء .
وأضاف المؤلف Paul Turner, مصدر
أعتقد ، ما كنت أتصل به DisableMemberRequest ، أنت تتصل إلغاء التنشيط . تعجبني فكرة استخدام DELETE لإلغاء عملية إلغاء التنشيط. ولكن مرة أخرى ، يكون ذلك مفيدًا إذا كانت عملية التعطيل الخاصة بك عملية طويلة الأمد.
وأضاف المؤلف Suhas, مصدر

الاقتراحات الأولى والثانية على حد سواء رائحة قليلا ، لأن لديهم فعل في URL. تحدد بنية RESTful الجيدة الموارد المشابهة للاسم فقط ، حيث يحدد بروتوكول HTTP مجموعة الأفعال القابلة للتطبيق على هذه الموارد.

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

من ما تقوله ، هناك عملية مهمة لتمكين أو تعطيل حساب المستخدم وعدم ارتياحك لكونه PUT أو PATCH ببساطة " "قيمة من true إلى false . إذا كان هذا يستغرق بعض الوقت ، ولديه حالة عابرة ، ومن المحتمل أن يكون شيئًا تريد أن تكون قادرًا على فضحه لمستخدمي واجهة برمجة التطبيقات حتى يكونوا على دراية بالعملية ، فمن المنطقي تحديد العملية نفسها كنوع من الموارد:

بدء التعطيل:

POST api/members/deactivations

الحصول على الحالة الحالية لإلغاء أو الإبلاغ عن الأنشطة التي حدثت:

GET api/members/deactivations/john.smith

إلغاء إلغاء التنشيط (اختياري):

DELETE api/members/deactivations/john.smith

إذا كان بإمكانك إعادة تنشيط حساب ، فقد يتبع ذلك نمطًا مماثلاً.

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

3
وأضاف
الفرق هو أن التعطيل هو بوضوح "شيء" يمكنك فهمه بشكل مستقل عن الموارد الأخرى ، ولكن لا يزال مرتبطًا بشدة بـ الأعضاء .
وأضاف المؤلف Paul Turner, مصدر
أعتقد ، ما كنت أتصل به DisableMemberRequest ، أنت تتصل إلغاء التنشيط . تعجبني فكرة استخدام DELETE لإلغاء عملية إلغاء التنشيط. ولكن مرة أخرى ، يكون ذلك مفيدًا إذا كانت عملية التعطيل الخاصة بك عملية طويلة الأمد.
وأضاف المؤلف Suhas, مصدر

أجبت للتو على سؤال مماثل في هنا .

الطريقة العملية للتفكير أو تطبيق REST كنقطة بداية (على الأقل أنها تعمل بالنسبة لي) هي التفكير بالطرق التالية:

1) استخدم فقط HTTP "GET/POST/PUT/DELETE" كطريقة لتخطيط إجراءات نطاقك. تمامًا كما هو الحال عند التعامل مع قاعدة البيانات ، يتم تعيين جميع إجراءاتك إلى CURD .

2) URI/URL هو تحديد الموارد فقط. يجب ألا يكون هناك أي "إجراءات" في URI أبدًا.

3) يجب أن تكون البيانات المتبادلة في نص رسائل HTTP. فقط لتبسيط المناقشات ، وليس الدخول في كيفية تصميم البيانات نفسها

حل Tragedian تبدو نظيفة.

تم التحديث لمعالجة التعليقاتSuhas "

REST ليس حول اصطلاح التسمية. يتعلق الأمر بكيفية التفكير في الموارد بدلاً من "الإجراءات" عند تصميم واجهة برمجة تطبيقات REST. يجب أن تفكر دائمًا في "Nonce" مثل المورد في URL/URI. لديك بالفعل جميع إجراءات CURD التي يجب أن يتم تعيين إجراءات النطاق لها ومعالجة الموارد في عنوان URL.

أنا أحب حل Tragedian ، فقط من أجل المناقشة ، يمكننا إعادة صياغة حل Tragedian مع مجموعة مماثلة من nonce ونمط URL مختلف إلى "أفضل" تناسب استخدام المجال المختلفة. قد لا يكون ما يلي هو الحل الأفضل للنطاق ، لكنهم يقدرون RESTful.

إزالة العضوية

  • DELETE api/membership/[member-id]/

الحصول على حالة العضوية

  • الحصول على api/membership/[member-id]/status/

إضافة عضوية

  • POST api/membership/[member-id]/

تم التحديث لمعالجة هذه المشكلة مع "DisabledMember" كمورد

في حالة استخدام "PUT DisabledMember" للقيام "بتعطيل العضو" كما هو مقترح من قبل Suhas ثم ماذا ستفعل الإجراءات التالية على مورد "DisabledMember"؟

DELETE DisabledMember ← تفعيلها مرة أخرى؟

POST DisabledMember -> ??

الحصول على DisabledMember - هذا هو واحد سهل☺

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

1
وأضاف
عندما قلت أنني أعني "لأسباب تجارية" فقط. مثلا إذا تم رفض DELETE على DisabledMember فسيكون ذلك لأسباب تتعلق بالأعمال.
وأضاف المؤلف Suhas, مصدر
هل يجب على كل مورد دعم كل إجراء HTTP؟ DELETE/POST على DisabledMember سيعود فقط HTTP 405 غير مسموح به
وأضاف المؤلف Suhas, مصدر
احصل على وجهة نظرك على تصميم حول الموارد. ولكني لا أرى تعليقًا على تصميمي الثالث حول تقديم مورد جديد يسمى DisabledMember . هل هناك أي مشاكل في هذا التصميم؟
وأضاف المؤلف Suhas, مصدر
أعتقد أن الاختلاف الوحيد بين حلّي الثاني والحلّ التراجيدي هو - أن يكون له اتفاقية تسمية أفضل.
وأضاف المؤلف Suhas, مصدر
REST ليس حول اصطلاح التسمية. يتعلق الأمر بكيفية التفكير في الموارد بدلاً من "الإجراءات" عند تصميم واجهة برمجة تطبيقات REST. يجب أن تفكر دائمًا في "Nonce" مثل المورد في URL/URI. لديك بالفعل جميع إجراءات CURD التي يجب أن يتم تعيين إجراءات النطاق لها ومعالجة الموارد في عنوان URL.
وأضاف المؤلف Ming Chan, مصدر
مع تصميم "DisabledMember" ، فإنه "يخفي" فعل "تعطيل" في المورد. لا يزال بإمكانك إجبارها على القيام بما تريده ولكن لن تكون مريحة بالنسبة لي.
وأضاف المؤلف Ming Chan, مصدر
ليس من الضروري أن يكون ذلك لأسباب تتعلق بالمنطق العملي. على سبيل المثال ، لعدم السماح بحذف ، قد يكون من غير المسموح لـ "إزالة" هذا المورد المحدد بعد إنشائه. أفكر عادة من خلال اسم المورد من خلال النظر في جميع الأفعال CURD للمساعدة في صنع خيار التصميم الخاص بي.
وأضاف المؤلف Ming Chan, مصدر

أجبت للتو على سؤال مماثل في هنا .

الطريقة العملية للتفكير أو تطبيق REST كنقطة بداية (على الأقل أنها تعمل بالنسبة لي) هي التفكير بالطرق التالية:

1) استخدم فقط HTTP "GET/POST/PUT/DELETE" كطريقة لتخطيط إجراءات نطاقك. تمامًا كما هو الحال عند التعامل مع قاعدة البيانات ، يتم تعيين جميع إجراءاتك إلى CURD .

2) URI/URL هو تحديد الموارد فقط. يجب ألا يكون هناك أي "إجراءات" في URI أبدًا.

3) يجب أن تكون البيانات المتبادلة في نص رسائل HTTP. فقط لتبسيط المناقشات ، وليس الدخول في كيفية تصميم البيانات نفسها

حل Tragedian تبدو نظيفة.

تم التحديث لمعالجة التعليقاتSuhas "

REST ليس حول اصطلاح التسمية. يتعلق الأمر بكيفية التفكير في الموارد بدلاً من "الإجراءات" عند تصميم واجهة برمجة تطبيقات REST. يجب أن تفكر دائمًا في "Nonce" مثل المورد في URL/URI. لديك بالفعل جميع إجراءات CURD التي يجب أن يتم تعيين إجراءات النطاق لها ومعالجة الموارد في عنوان URL.

أنا أحب حل Tragedian ، فقط من أجل المناقشة ، يمكننا إعادة صياغة حل Tragedian مع مجموعة مماثلة من nonce ونمط URL مختلف إلى "أفضل" تناسب استخدام المجال المختلفة. قد لا يكون ما يلي هو الحل الأفضل للنطاق ، لكنهم يقدرون RESTful.

إزالة العضوية

  • DELETE api/membership/[member-id]/

الحصول على حالة العضوية

  • الحصول على api/membership/[member-id]/status/

إضافة عضوية

  • POST api/membership/[member-id]/

تم التحديث لمعالجة هذه المشكلة مع "DisabledMember" كمورد

في حالة استخدام "PUT DisabledMember" للقيام "بتعطيل العضو" كما هو مقترح من قبل Suhas ثم ماذا ستفعل الإجراءات التالية على مورد "DisabledMember"؟

DELETE DisabledMember ← تفعيلها مرة أخرى؟

POST DisabledMember -> ??

الحصول على DisabledMember - هذا هو واحد سهل☺

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

1
وأضاف
عندما قلت أنني أعني "لأسباب تجارية" فقط. مثلا إذا تم رفض DELETE على DisabledMember فسيكون ذلك لأسباب تتعلق بالأعمال.
وأضاف المؤلف Suhas, مصدر
هل يجب على كل مورد دعم كل إجراء HTTP؟ DELETE/POST على DisabledMember سيعود فقط HTTP 405 غير مسموح به
وأضاف المؤلف Suhas, مصدر
احصل على وجهة نظرك على تصميم حول الموارد. ولكني لا أرى تعليقًا على تصميمي الثالث حول تقديم مورد جديد يسمى DisabledMember . هل هناك أي مشاكل في هذا التصميم؟
وأضاف المؤلف Suhas, مصدر
أعتقد أن الاختلاف الوحيد بين حلّي الثاني والحلّ التراجيدي هو - أن يكون له اتفاقية تسمية أفضل.
وأضاف المؤلف Suhas, مصدر
REST ليس حول اصطلاح التسمية. يتعلق الأمر بكيفية التفكير في الموارد بدلاً من "الإجراءات" عند تصميم واجهة برمجة تطبيقات REST. يجب أن تفكر دائمًا في "Nonce" مثل المورد في URL/URI. لديك بالفعل جميع إجراءات CURD التي يجب أن يتم تعيين إجراءات النطاق لها ومعالجة الموارد في عنوان URL.
وأضاف المؤلف Ming Chan, مصدر
مع تصميم "DisabledMember" ، فإنه "يخفي" فعل "تعطيل" في المورد. لا يزال بإمكانك إجبارها على القيام بما تريده ولكن لن تكون مريحة بالنسبة لي.
وأضاف المؤلف Ming Chan, مصدر
ليس من الضروري أن يكون ذلك لأسباب تتعلق بالمنطق العملي. على سبيل المثال ، لعدم السماح بحذف ، قد يكون من غير المسموح لـ "إزالة" هذا المورد المحدد بعد إنشائه. أفكر عادة من خلال اسم المورد من خلال النظر في جميع الأفعال CURD للمساعدة في صنع خيار التصميم الخاص بي.
وأضاف المؤلف Ming Chan, مصدر

لدى العضو حالة نشطة ومعطل

إذاً الوضع هو خاصية للكيان/الموارد العضو ؛ في هذه الحالة لماذا لا تريد استخدام طريقة PUT ببساطة على مورد الأعضاء مع تعيين الحالة إلى معطل؟

0
وأضاف
لدى العضو الكثير من المجالات الأخرى التي قد يرغب العملاء في تحديثها. يستخدمونها وضعت في هذا الوضع. لا تؤدي هذه التحديثات عادةً إلى تشغيل أي سير عمل آخر. إنها تحديثات بسيطة لمخزن البيانات الخاص بنا. ولكن تعطيل أحد الأعضاء هو سير عمل معقد ، وبالتالي يجب فصله عن تحديث الأعضاء كمفهوم.
وأضاف المؤلف Suhas, مصدر
هل تقصد سلسلة الاستعلام؟ أشك في أنني سوف تستخدم سلاسل الاستعلام على آخر لإرسال المعلمات. وظيفة واحدة لحكمهم جميعا تبدو وكأنها خرق ل SRP لي.
وأضاف المؤلف Suhas, مصدر
لديك مورد تحت أعضاء/{someId}. يمكنك استخدام GET لاسترداد هذا المورد ، DELETE - لحذف تلك الموارد ، PUT - لتحديث تلك الموارد. طريقة POST مجانية ، لذا يمكنك استخدامها لتفعيل تنشيط عضويتك
وأضاف المؤلف maks, مصدر
إذا كان لديك العديد من حالات بدء عملية سير العمل ، يمكن تحديدها بواسطة معلمات مختلفة إلى طريقة POST
وأضاف المؤلف maks, مصدر

لدى العضو حالة نشطة ومعطل

إذاً الوضع هو خاصية للكيان/الموارد العضو ؛ في هذه الحالة لماذا لا تريد استخدام طريقة PUT ببساطة على مورد الأعضاء مع تعيين الحالة إلى معطل؟

0
وأضاف
لدى العضو الكثير من المجالات الأخرى التي قد يرغب العملاء في تحديثها. يستخدمونها وضعت في هذا الوضع. لا تؤدي هذه التحديثات عادةً إلى تشغيل أي سير عمل آخر. إنها تحديثات بسيطة لمخزن البيانات الخاص بنا. ولكن تعطيل أحد الأعضاء هو سير عمل معقد ، وبالتالي يجب فصله عن تحديث الأعضاء كمفهوم.
وأضاف المؤلف Suhas, مصدر
هل تقصد سلسلة الاستعلام؟ أشك في أنني سوف تستخدم سلاسل الاستعلام على آخر لإرسال المعلمات. وظيفة واحدة لحكمهم جميعا تبدو وكأنها خرق ل SRP لي.
وأضاف المؤلف Suhas, مصدر
لديك مورد تحت أعضاء/{someId}. يمكنك استخدام GET لاسترداد هذا المورد ، DELETE - لحذف تلك الموارد ، PUT - لتحديث تلك الموارد. طريقة POST مجانية ، لذا يمكنك استخدامها لتفعيل تنشيط عضويتك
وأضاف المؤلف maks, مصدر
إذا كان لديك العديد من حالات بدء عملية سير العمل ، يمكن تحديدها بواسطة معلمات مختلفة إلى طريقة POST
وأضاف المؤلف maks, مصدر

إذا كانت عملية قصيرة لتعطيل المستخدم ، فلماذا لا تستخدم HTTP PATCH؟

شاهد هذه الإجابة على سؤال مماثل

0
وأضاف
لقد أضفت تفاصيل حول الأسئلة. لا يعد تعطيل أحد الأعضاء تحديثًا بسيطًا.
وأضاف المؤلف Suhas, مصدر