আমার REST এপিআইতে প্যাচ বা পুট ব্যবহার করা উচিত?

Question

আমি নিম্নলিখিত দৃশ্যের জন্য উপযুক্ত পদ্ধতির সাথে আমার বিশ্রামের সমাপ্তিটি নকশা করতে চাই।

একটি গ্রুপ আছে। প্রতিটি গ্রুপের একটি স্ট্যাটাস রয়েছে। গোষ্ঠীটি প্রশাসক দ্বারা সক্রিয় বা নিষ্ক্রিয় করা যেতে পারে।

আমি আমার শেষ পয়েন্ট হিসাবে নকশা করা উচিত?

PUT /groups/api/v1/groups/{group id}/status/activate

অথবা

PATCH /groups/api/v1/groups/{group id}

with request body like 
{action:activate|deactivate}

Comments

দুজনেই ভাল আছেন। তবে জেএসএন প্যাচ ফর্ম্যাটের (সরঞ্জাম. ietf.org/html/rfc6902 ) আরএফসিকে একবার দেখুন । প্যাচ লোডের জন্য কিছু ধরণের ডিফ / প্যাচ ডকুমেন্ট পাওয়ার প্রত্যাশা করে (এবং কাঁচা জেএসওএন এর মধ্যে একটি নয়)।

— জের্ন ওয়াইল্ড

@ জার্নওয়েল্ট নং, পুট একটি ভয়ঙ্কর পছন্দ হবে। আপনি সেখানে কি রাখছেন? প্যাচ হ'ল একমাত্র বোধগম্য বিকল্প। ভাল, এই ক্ষেত্রে আপনি প্রশ্নে উপস্থাপিত প্যাচ ফর্ম্যাটটি ব্যবহার করতে পারেন, এবং কেবল পুট পদ্ধতিটি ব্যবহার করতে পারেন; পুট উদাহরণটি ঠিক ভুল।

— থোকোশম্যান

এক বা একাধিক বৈশিষ্ট্যকে স্ট্যান্ডলোন রিসোর্স হিসাবে প্রকাশ করার ক্ষেত্রে কোনও ভুল নেই যা কোনও ক্লায়েন্ট PUT দিয়ে GET পেতে এবং সংশোধন করতে পারে। তবে, হ্যাঁ, ইউআরএলটি তখন / গোষ্ঠী / এপিআই / ভি 1 / গোষ্ঠী / {গোষ্ঠী আইডি} / স্থিতি হওয়া উচিত যেখানে আপনি "সক্রিয়" বা "নিষ্ক্রিয়" বা GET বর্তমান অবস্থা পড়তে পারেন।

— জার্ন ওয়াইল্ড

এখানে PATCH কীভাবে ব্যবহার করা উচিত তার একটি ভাল ব্যাখ্যা এখানে দেওয়া হয়েছে: উইলিয়ামদুরানড.ফ

— r /

" activate" যথেষ্ট পরিমাণে RESTful নির্মাণ নয়। আপনি সম্ভবত status"সক্রিয়" বা "ডিএ্যাকটিভ" এ আপডেট করার চেষ্টা করছেন । এই ক্ষেত্রে আপনি .../statusশরীরে "সক্রিয়" বা "ডিএকটিভ" স্ট্রিং দিয়ে প্যাচ করতে পারেন । অথবা আপনি যদি কোনও বুলেটিয়ান আপডেট করার চেষ্টা করছেন status.active, আপনি .../status/activeশরীরে বুলিয়ানটি দিয়ে প্যাচ করতে পারেন

— অগি গার্ডনার

Answer 1

PATCHগ্রুপ আইডি - পদ্ধতি আপনি যদি একটি বিদ্যমান সম্পদ আপডেট করছি যেমন সঠিক পছন্দ এখানে। PUTআপনি যদি কেবল কোনও সংস্থার পুরোপুরি প্রতিস্থাপন করেন তবেই ব্যবহার করা উচিত ।

আংশিক সম্পদ সংশোধন সম্পর্কিত আরও তথ্য আরএফসি 5789 এ উপলব্ধ । বিশেষত, PUTপদ্ধতিটি নীচে বর্ণিত:

হাইপারটেক্সট ট্রান্সফার প্রোটোকল (এইচটিটিপি) প্রসারিত বেশ কয়েকটি অ্যাপ্লিকেশনের আংশিক সংস্থান পরিবর্তন করতে একটি বৈশিষ্ট্য প্রয়োজন। বিদ্যমান HTTP PUT পদ্ধতিটি কেবলমাত্র একটি দস্তাবেজের সম্পূর্ণ প্রতিস্থাপনের অনুমতি দেয়। এই প্রস্তাবটি একটি বিদ্যমান এইচটিটিপি রিসোর্সটি সংশোধন করার জন্য একটি নতুন এইচটিটিপি পদ্ধতি, প্যাচএইচসিএইচ যুক্ত করে।

Comments

ন্যায়সঙ্গত হতে, আপনি স্ট্রিংটি 'অ্যাক্টিভেট' বা রিসোর্সটিতে 'নিষ্ক্রিয়' করতে পারেন। যেহেতু (মনে হয়) কেবল টগল করার জন্য এক জিনিস হ'ল, সম্পূর্ণরূপে এটি প্রতিস্থাপন করা এত বিশাল চুক্তি নয়। এবং এটি একটি (তুচ্ছ) আরও ছোট অনুরোধের অনুমতি দেয়।

— thecoshman

এটি লক্ষণীয় যে, আরএফসি 5789 এখনও প্রস্তাবের পর্যায়ে রয়েছে এবং এটি আনুষ্ঠানিকভাবে গৃহীত হয়নি এবং বর্তমানে এটি 'ইরতাটি বিদ্যমান' হিসাবে চিহ্নিত করা হয়েছে। এই 'সেরা অনুশীলন' অত্যন্ত বিতর্কিত এবং প্রযুক্তিগতভাবে প্যাচচএইচ এখনও এইচটিটিপি স্ট্যান্ডার্ডের অংশ নয়।

— ফিশস্পেন 0

কয়েক বছর পরে কেবল আমার 2 সেন্ট: আপনি স্থিতিটিকে নিজেকে একটি উত্স হিসাবে বিবেচনা করতে পারেন এবং যদি তাই হয় তবে / পিটিএসের বিপরীতে PUT ব্যবহার করার কারণে প্রযুক্তিগতভাবে স্থিতির সংস্থানটি সেই শেষ পর্যায়ে প্রতিস্থাপন করা হবে।

— জোনো স্টুয়ার্ট

আমি দস্তাবেজের বিরুদ্ধে তর্ক করার সাহস করব, যদিও এটি "" "আরএফসি। দস্তাবেজগুলি সূচিত করে যে কোনও উত্সের কেবলমাত্র একটি অংশ পরিবর্তন করতে আপনার প্যাচচ ব্যবহার করা উচিত, তবে এটি গুরুত্বপূর্ণ বিষয়টিকে বাদ দিয়েছিল যে প্যাচচ পদ্ধতিটি একটি আদর্শবিহীন পদ্ধতি হিসাবে সংজ্ঞায়িত হয়েছে। কেন? যদি পুট পদ্ধতিটি পুরো রিসোর্সের আপডেট / প্রতিস্থাপনের কথা মাথায় রেখে তৈরি করা হয়েছিল, তবে প্যাচচ পদ্ধতিটি কেন পুটের মতো আদর্শবান পদ্ধতি হিসাবে তৈরি করা হয়নি, যদি এর উদ্দেশ্যটি কেবল কোনও সংস্থার অংশ আপডেট করা হত? আমার কাছে এটি আপডেটের আদর্শের চেয়ে বেশি পার্থক্য দেখায়, যেমন "a = 5" (PUT) এবং "a = a + 5" (PATCH)। উভয়ই পুরো সম্পদ আপডেট করতে পারে।

— ম্লাদেন বি।

Answer 2

আর বাকি রিসোর্স ঘোরা

(যা সত্য নয়, কারণ এটি প্রতিনিধিত্বমূলক, তবে এটি আরইএসটিতে রিসোর্সের গুরুত্ব স্মরণ করার জন্য একটি ভাল কৌশল)।

সম্পর্কে PUT /groups/api/v1/groups/{group id}/status/activate: আপনি কোনও "অ্যাক্টিভেট" আপডেট করছেন না । "অ্যাক্টিভেট" জিনিস নয়, এটি একটি ক্রিয়াপদ। ক্রিয়াগুলি কখনই ভাল সংস্থান হয় না। থাম্বের একটি নিয়ম: যদি ক্রিয়া, একটি ক্রিয়াটি ইউআরএলটিতে থাকে তবে এটি সম্ভবত বিশ্রামের নয় ।

এর বদলে আপনি কি করছেন? হয় আপনি "যোগ" হয়, "সরানো হচ্ছে" বা "আপডেট" একটি অ্যাক্টিভেশন একটি গোষ্ঠীতে, অথবা যদি আপনি পছন্দ: একটি গোষ্ঠীতে একটি "স্থিতি" -resource কাজে লাগাতে হয়। ব্যক্তিগতভাবে, আমি "অ্যাক্টিভেশনস" ব্যবহার করব কারণ এগুলি "স্ট্যাটাস" ধারণাটির চেয়ে কম অস্পষ্ট: একটি স্ট্যাটাস তৈরি করা অস্পষ্ট, একটি অ্যাক্টিভেশন তৈরি করা নয়।

• POST /groups/{group id}/activation একটি অ্যাক্টিভেশন তৈরি করে (বা তৈরির অনুরোধ করে)।
• PATCH /groups/{group id}/activationবিদ্যমান অ্যাক্টিভেশন সম্পর্কিত কিছু বিবরণ আপডেট করে। যেহেতু একটি গোষ্ঠীর একটি মাত্র অ্যাক্টিভেশন রয়েছে, তাই আমরা জানি কী অ্যাক্টিভেশন-রিসোর্স আমরা উল্লেখ করছি।
• PUT /groups/{group id}/activationপুরানো সক্রিয়করণ সন্নিবেশ-বা-প্রতিস্থাপন করে। যেহেতু একটি গোষ্ঠীর একটি মাত্র অ্যাক্টিভেশন রয়েছে, তাই আমরা জানি কী অ্যাক্টিভেশন-রিসোর্স আমরা উল্লেখ করছি।
• DELETE /groups/{group id}/activation অ্যাক্টিভেশন বাতিল বা মুছে ফেলবে।

এই প্যাটার্নটি কার্যকর যখন কোনও গ্রুপের "অ্যাক্টিভেশন" এর পার্শ্ব-প্রতিক্রিয়া থাকে যেমন পেমেন্ট করা হচ্ছে, মেলগুলি প্রেরণ করা হচ্ছে ইত্যাদি। কেবলমাত্র POST এবং PATCH এর মতো পার্শ্ব প্রতিক্রিয়া হতে পারে। উদাহরণস্বরূপ যখন কোনও অ্যাক্টিভেশন মুছে ফেলার প্রয়োজন হয়, বলুন, মেলের মাধ্যমে ব্যবহারকারীদের জানান, ডিলিট সঠিক পছন্দ নয়; যে ক্ষেত্রে আপনি সম্ভবত করতে চান একটি নিষ্ক্রিয় সংস্থান তৈরি : POST /groups/{group_id}/deactivation।

এই নির্দেশিকাগুলি অনুসরণ করা একটি ভাল ধারণা, কারণ এই স্ট্যান্ডার্ড চুক্তিটি আপনার ক্লায়েন্টদের জন্য এবং ক্লায়েন্ট এবং আপনার মধ্যে থাকা সমস্ত প্রক্সি এবং স্তরগুলি জেনে রাখে কখন এটি আবার চেষ্টা করা নিরাপদ, এবং কখন নয় know আসুন ধরা যাক ক্লায়েন্টটি ফ্লকি ওয়াইফাই সহ কোথাও রয়েছে এবং এর ব্যবহারকারী "নিষ্ক্রিয়" ক্লিক করে যা একটি ট্রিগার করে DELETE: যদি এটি ব্যর্থ হয় তবে ক্লায়েন্টটি কেবল 404, 200 বা এটি পরিচালনা করতে পারে এমন অন্য কিছু না পাওয়া পর্যন্ত পুনরায় চেষ্টা করতে পারে। তবে এটি যদি ট্রিগার করে তবে এটি POST to deactivationপুনরায় চেষ্টা করতে না জানে: পোষ্ট এটি বোঝায়।
যে কোনও ক্লায়েন্টের এখন একটি চুক্তি রয়েছে, যা অনুসরণ করার পরে, 42 টি ইমেলগুলি "আপনার গ্রুপটি নিষ্ক্রিয় করা হয়েছে" প্রেরণের বিরুদ্ধে সুরক্ষা দেবে, কেবলমাত্র তার এইচটিটিপি-লাইব্রেরি ব্যাকএন্ডে কলটি আবার চেষ্টা করে চলেছে বলে।

একটি একক বৈশিষ্ট্য আপডেট করা হচ্ছে: PATCH ব্যবহার করুন

PATCH /groups/{group id}

আপনি যদি কোনও বৈশিষ্ট্য আপডেট করতে চান তবে। যেমন "স্থিতি" সেট করা যেতে পারে এমন গোষ্ঠীতে একটি বৈশিষ্ট্য হতে পারে। "স্ট্যাটাস" এর মতো একটি বৈশিষ্ট্যটি প্রায়শই মানগুলির শ্বেত তালিকাতে সীমাবদ্ধ রাখার জন্য ভাল প্রার্থী হয়। উদাহরণগুলি কিছু অপরিজ্ঞাত JSON- স্কিম ব্যবহার করে:

PATCH /groups/{group id} { "attributes": { "status": "active" } }
response: 200 OK

PATCH /groups/{group id} { "attributes": { "status": "deleted" } }
response: 406 Not Acceptable

পার্শ্ব প্রতিক্রিয়া ছাড়াই রিসোর্স প্রতিস্থাপন, PUT ব্যবহার করুন।

PUT /groups/{group id}

আপনি যদি একটি সম্পূর্ণ গ্রুপ প্রতিস্থাপন করতে চান। এটি অগত্যা এর অর্থ এই নয় যে সার্ভারটি আসলে একটি নতুন গোষ্ঠী তৈরি করে এবং পুরাতনটিকে বাইরে ফেলে দেয়, উদাহরণস্বরূপ আইডিগুলি একই থাকবে। কিন্তু ক্লায়েন্ট জন্য, এই রাখুন কি করতে ক্লায়েন্ট তিনি একটি সম্পূর্ণ নতুন আইটেম, সার্ভারের প্রতিক্রিয়া উপর ভিত্তি করে পায় অনুমান করা উচিত: মানে।

ক্লায়েন্টকে কোনও PUTঅনুরোধের ক্ষেত্রে সর্বদা পুরো রিসোর্সটি প্রেরণ করা উচিত, একটি নতুন আইটেম তৈরি করার জন্য প্রয়োজনীয় সমস্ত ডেটা থাকা: সাধারণত পোষ্ট-তৈরির মতো একই ডেটার প্রয়োজন হয়।

PUT /groups/{group id} { "attributes": { "status": "active" } }
response: 406 Not Acceptable

PUT /groups/{group id} { "attributes": { "name": .... etc. "status": "active" } }
response: 201 Created or 200 OK, depending on whether we made a new one.

খুব গুরুত্বপূর্ণ প্রয়োজন হ'ল PUTআদর্শবান: যদি কোনও গ্রুপ আপডেট করার সময় আপনার পার্শ্ব প্রতিক্রিয়া প্রয়োজন হয় (বা একটি অ্যাক্টিভেশন পরিবর্তন করা হয়), আপনার ব্যবহার করা উচিত PATCH। সুতরাং, যখন আপডেটের ফলাফলগুলি যেমন কোনও মেল প্রেরণ করা হয় তখন ব্যবহার করবেন না PUT।

Comments

এটি আমার কাছে খুব তথ্যপূর্ণ ছিল। "এই প্যাটার্নটি কার্যকর যখন কোনও গ্রুপের" অ্যাক্টিভেশন "এর পার্শ্ব-প্রতিক্রিয়া হয়" - এই প্যাটার্নটি কীভাবে কার্যকর হয়, বিশেষত যখন ওপি প্রাথমিক প্রান্তের বিপরীতে ক্রিয়াকলাপগুলির পার্শ্ব প্রতিক্রিয়া হয় সে ক্ষেত্রে

— আব্দুল

@ আবদুল, প্যাটার্নটি অনেক কারণে কার্যকর, তবে ক্ষতিকারক পার্শ্ব-প্রতিক্রিয়াগুলি, এটি একটি ক্লায়েন্টের কাছে খুব স্পষ্ট হওয়া উচিত, কোনও ক্রিয়াকলাপ কী প্রভাব ফেলে। যখন বলুন, কোনও আইওএস অ্যাপ পুরো অ্যাড্রেসবুকটিকে "পরিচিতি" হিসাবে প্রেরণ করার সিদ্ধান্ত নিয়েছে তবে এটি একটি স্পষ্টতই পরিষ্কার হওয়া উচিত যে কোনও পরিচিতির তৈরি, হালনাগাদ, মুছা ইত্যাদির কী পার্শ্ব-প্রতিক্রিয়া রয়েছে। উদাহরণস্বরূপ, সমস্ত পরিচিতিকে ভর-মেইলিং এড়ানোর জন্য।

— বার্কস

RESTfull PUT এ সত্তাগুলি পরিচয়ও পরিবর্তন করতে পারে - উদাহরণস্বরূপ প্রাথমিক কে আইডি যেখানে এটি একটি সমান্তরাল অনুরোধ ব্যর্থ হতে পারে। (উদাহরণস্বরূপ পুরো সত্তাকে আপডেট করার জন্য কয়েকটি সারি মুছে ফেলা এবং নতুন সত্তা যুক্ত করা দরকার) যেখানে প্যাচটিএইচ কখনই এটি করতে সক্ষম হয় না, অন্যান্য "অ্যাপ্লিকেশনগুলিকে" প্রভাবিত না করে সীমাহীন সংখ্যক PATCH অনুরোধের অনুমতি দেয়

— পাইওটর কুলা

খুব সহায়ক উত্তর। ধন্যবাদ! আমি লুকের জবাবের মতো একটি মন্তব্যও যুক্ত করব, পয়েন্ট / প্যাচএইচসি-র মধ্যে পার্থক্য কেবল পুরো / আংশিক আপডেট নয়, এটি আদর্শেরও আলাদা যেটিও। এটি কোনও ভুল ছিল না, এটি একটি উদ্দেশ্যমূলক সিদ্ধান্ত ছিল এবং আমি মনে করি যে এইচটিটিপি পদ্ধতির ব্যবহারের সিদ্ধান্ত নেওয়ার সময় অনেক লোক এটিকে বিবেচনায় নেবে না।

— ম্লাদেন বি।

মডেলগুলির মতো @ রিচরেমার পরিষেবাদিগুলি অভ্যন্তরীণ বিমূর্ততা। আরইএসটি-এন্ডপয়েন্টস-এবং-ওআরএম-মডেল বা এমনকি ডাটাবেস টেবিলের মধ্যে 1-1 সম্পর্ক থাকা যেমন একটি দুর্বল বিমূর্ততা, তেমন পরিষেবাগুলি প্রকাশ করাও এটি দুর্বল বিমূর্ততা। বাইরেরটি, আপনার এপিআই, অবশ্যই ডোমেন মডেলগুলির সাথে যোগাযোগ করবে। আপনি কীভাবে এগুলিকে অভ্যন্তরীণভাবে প্রয়োগ করেন তা এপিআই-তে উদ্বেগের বিষয় নয়। আপনার API পরিবর্তন না করেই আপনি অ্যাক্টিভেশন সার্ভিসেস থেকে সিকিউআরএস ভিত্তিক অ্যাক্টিভেশন প্রবাহে চলে যেতে পারেন free

— বার্ক

Answer 3

আমি প্যাচ ব্যবহার করার পরামর্শ দেব, কারণ আপনার সংস্থান 'গোষ্ঠী'র অনেক বৈশিষ্ট্য রয়েছে তবে এই ক্ষেত্রে আপনি কেবল অ্যাক্টিভেশন ক্ষেত্রটি আপডেট করছেন (আংশিক পরিবর্তন)

আরএফসি 5789 অনুসারে ( https://tools.ietf.org/html/rfc5789 )

বিদ্যমান HTTP PUT পদ্ধতিটি কেবলমাত্র একটি দস্তাবেজের সম্পূর্ণ প্রতিস্থাপনের অনুমতি দেয়। এই প্রস্তাবটি একটি বিদ্যমান এইচটিটিপি রিসোর্সটি সংশোধন করার জন্য একটি নতুন এইচটিটিপি পদ্ধতি, প্যাচএইচসিএইচ যুক্ত করে।

এছাড়াও, আরও বিশদে

PUT এবং PATCH অনুরোধগুলির মধ্যে পার্থক্য প্রতিবেদন
-ইউআরআই দ্বারা চিহ্নিত সংস্থানটি সংশোধিত করার জন্য সার্ভারটি যেভাবে আবদ্ধ সত্তাকে প্রক্রিয়াজাত করে তাতে প্রতিফলিত হয় । একটি পুট অনুরোধে, জড়িত সত্তাটিকে
উত্স সার্ভারে সঞ্চিত সংস্থার পরিবর্তিত সংস্করণ হিসাবে বিবেচনা করা হয় এবং ক্লায়েন্ট অনুরোধ করে যে সঞ্চিত সংস্করণটি
প্রতিস্থাপন করা হোক। প্যাচএইচ, তবে, সংযুক্ত সত্তায় নির্দেশাবলীর একটি সেট রয়েছে যা বর্ণনা করে যে কীভাবে বর্তমানে
উত্সের সার্ভারে বসবাসরত কোনও সংস্থানটি নতুন সংস্করণ তৈরি করতে পরিবর্তন করা উচিত। অনুরোধ-ইউআরআই দ্বারা চিহ্নিত সংস্থানটিকে প্যাচ পদ্ধতিটি প্রভাবিত করে এবং এটি
অন্যান্য সংস্থানগুলিতেও পার্শ্ব প্রতিক্রিয়া থাকতে পারে; অর্থাত্ নতুন সংস্থানসমূহ

PATCH প্রয়োগ করে তৈরি বা বিদ্যমান সংশোধিত হতে পারে ।

প্যাচচ এইচআর [RFC2616], বিভাগ 9.1 দ্বারা সংজ্ঞায়িত হিসাবে নিরাপদ বা আদর্শবান নয়।

ক্লায়েন্টদের PUT পরিবর্তে PATCH কখন ব্যবহার করবেন তা চয়ন করতে হবে। জন্য
উদাহরণস্বরূপ, যদি প্যাচ ডকুমেন্ট আকার আকার চেয়ে বড়
নতুন রিসোর্স তথ্য যে একটি স্থাপনকারি ব্যবহার করা হবে, তাহলে এটি করা হতে পারে
ব্যবহার PUT পরিবর্তে প্যাচ জ্ঞান। পোষ্টের সাথে তুলনা করা আরও বেশি কঠিন কারণ পোষ্টটি বিভিন্নভাবে বিভিন্নভাবে ব্যবহৃত হয়
এবং সার্ভারটি বেছে নিলে PUT এবং প্যাচ-এর মতো ক্রিয়াকলাপকে অন্তর্ভুক্ত করতে পারে। যদি
অপারেশনটি পূর্বাভাসযোগ্য উপায়ে অনুরোধ-ইউআরআই দ্বারা চিহ্নিত সংস্থানটি সংশোধন না করে, PATCH
বা PUT এর পরিবর্তে POST বিবেচনা করা উচিত ।

PATCH এর প্রতিক্রিয়া কোডটি

২০৪ টি প্রতিক্রিয়া কোড ব্যবহার করা হয়েছে কারণ প্রতিক্রিয়াটি কোনও বার্তা বহন করে না (যা ২০০ কোডের সাথে একটি প্রতিক্রিয়া ধারণ করে)। নোট করুন যে অন্যান্য সাফল্য কোডগুলিও ব্যবহার করা যেতে পারে।

এছাড়াও thttp: //restcookbook.com/HTTP%20Methods/patch/ দেখুন

ক্যাভেট: একটি পিআইএটিচএল বাস্তবায়নকারী এপিআই অবশ্যই পরমাণু প্যাচ করবে। কোনও জিইটি দ্বারা অনুরোধ করা হলে সংস্থানগুলি অর্ধ-প্যাচ করা সম্ভব নয়।

Answer 4

যেহেতু আপনি আরআইএসটি আর্কিটেকচারাল স্টাইল ব্যবহার করে কোনও এআইপি ডিজাইন করতে চান আপনাকে কোন ধারণাটি সম্পদ হিসাবে প্রকাশের জন্য যথেষ্ট গুরুত্বপূর্ণ তা নির্ধারণ করার জন্য আপনার ব্যবহারের ক্ষেত্রে চিন্তা করতে হবে। আপনি যদি উপ-সংস্থান হিসাবে কোনও গোষ্ঠীর স্থিতি প্রকাশের সিদ্ধান্ত নেন তবে আপনি এটিকে নিম্নলিখিত ইউআরআই দিতে এবং জিইটি এবং পিইটি উভয় পদ্ধতির জন্য সমর্থন প্রয়োগ করতে পারেন:

/groups/api/groups/{group id}/status

পরিবর্তনের জন্য প্যাচএইচসি সম্পর্কিত এই পদ্ধতির খারাপ দিকটি হ'ল আপনি কোনও গোষ্ঠীর একাধিক সম্পত্তি পরমাণু ও লেনদেনের ক্ষেত্রে পরিবর্তন করতে সক্ষম হবেন না। যদি লেনদেনের পরিবর্তনগুলি গুরুত্বপূর্ণ হয় তবে প্যাচচ্যাচ ব্যবহার করুন।

আপনি যদি কোনও গোষ্ঠীর উপ-উত্স হিসাবে স্থিতিটি প্রকাশ করার সিদ্ধান্ত নেন তবে এটি দলের প্রতিনিধিত্বের একটি লিঙ্ক হওয়া উচিত। উদাহরণস্বরূপ, যদি এজেন্টটি 123 গোষ্ঠী পায় এবং এক্সএমএল গ্রহণ করে তবে প্রতিক্রিয়া সংস্থায় এটি থাকতে পারে:

<group id="123">
  <status>Active</status>
  <link rel="/linkrels/groups/status" uri="/groups/api/groups/123/status"/>
  ...
</group>

REST আর্কিটেকচারাল শৈলীর অ্যাপ্লিকেশন স্টেট শর্তের ইঞ্জিন হিসাবে হাইপারমিডিয়া পূরণের জন্য একটি হাইপারলিংক প্রয়োজন ।

Answer 5

আমি সাধারণত কিছুটা সহজ কিছু পছন্দ করবো, যেমন activate/ deactivateসাব-রিসোর্স (যার সাথে একটি Linkশিরোনাম দ্বারা যুক্ত rel=service)।

POST /groups/api/v1/groups/{group id}/activate

অথবা

POST /groups/api/v1/groups/{group id}/deactivate

ভোক্তাদের জন্য, এই ইন্টারফেসটি মৃত-সহজ, এবং এটি পৃথক সংস্থান হিসাবে "অ্যাক্টিভেশনস" ধারণায় আপনাকে ঝুঁকি না দিয়ে REST নীতি অনুসরণ করে।

Answer 6

এই জাতীয় আচরণ বাস্তবায়নের জন্য একটি সম্ভাব্য বিকল্প হ'ল

PUT /groups/api/v1/groups/{group id}/status
{
    "Status":"Activated"
}

এবং স্পষ্টতই, কারও যদি এটি নিষ্ক্রিয় করা দরকার হয়, PUTতার Deactivatedজেএসএনে স্থিতি থাকবে ।

ভর সক্রিয়করণ / নিষ্ক্রিয়করণের প্রয়োজনীয়তার ক্ষেত্রে, PATCHগেমটিতে প্রবেশ করতে পারে (সঠিক গোষ্ঠীর জন্য নয়, তবে groupsসংস্থার জন্য :

PATCH /groups/api/v1/groups
{
    { “op”: “replace”, “path”: “/group1/status”, “value”: “Activated” },
    { “op”: “replace”, “path”: “/group7/status”, “value”: “Activated” },
    { “op”: “replace”, “path”: “/group9/status”, “value”: “Deactivated” }
}

সাধারণভাবে এটি @ অ্যান্ড্রু ডব্রোভলস্কি পরামর্শ হিসাবে ধারণা করছেন তবে সঠিক উপলব্ধিতে সামান্য পরিবর্তন রয়েছে।