রেস্ট - শরীরে আইডি রাখুন নাকি?

Question 1

ধরা যাক আমি লোকদের জন্য একটি বিশ্রামের রিসোর্স রাখতে চাই, যেখানে ক্লায়েন্ট আইডি নির্ধারণ করতে সক্ষম।

কোনও ব্যক্তিকে এরকম দেখাচ্ছে: {"id": <UUID>, "name": "Jimmy"}

এখন, ক্লায়েন্টকে কীভাবে এটি সংরক্ষণ করতে হবে (বা "পুট")?

PUT /person/UUID {"id": <UUID>, "name": "Jimmy"} - এখন আমাদের কাছে এই অদ্ভুত সদৃশটি রয়েছে যা আমাদের সর্বদা যাচাই করতে হবে: দেহের আইডিটি কি পথের সাথে মিলে যায়?
অসমমিতি উপস্থাপনা:
- PUT /person/UUID {"name": "Jimmy"}
- GET /person/UUID প্রত্যাবর্তন {"id": <UUID>, "name": "Jimmy"}
শরীরে কোনও আইডি নেই - কেবল অবস্থানে আইডি:
- PUT /person/UUID {"name": "Jimmy"}
- GET /person/UUID প্রত্যাবর্তন {"name": "Jimmy"}
POSTক্লায়েন্ট দ্বারা আইডি উত্পন্ন হওয়ার পরে কোনও ধরণেরই ভাল ধারণা বলে মনে হয় না।

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

Question 2

বিভিন্ন পড়ার / লেখার মডেল থাকার ক্ষেত্রে কোনও ভুল নেই: ক্লায়েন্ট একটি রিসোর্স উপস্থাপনা লিখতে পারে যেখানে সার্ভারের পরে এতে যুক্ত / গণনা করা উপাদানগুলি (বা এমনকি সম্পূর্ণ আলাদা উপস্থাপনা - এমনকি কোনও বিপরীতে কিছুই নেই) এমন একটি উত্সের উপস্থাপনা লিখতে পারে that , একমাত্র প্রয়োজন হ'ল পুটকে উত্স তৈরি বা প্রতিস্থাপন করা উচিত)।

সুতরাং আমি (2) এ অসমमित সমাধানের জন্য যাব এবং লিখতে গিয়ে সার্ভারের পাশে "দুষ্টু সদৃশ চেক" এড়াতে চাই:

PUT /person/UUID {"name": "Jimmy"}

GET /person/UUID returns {"id": <UUID>, "name": "Jimmy"}

Question 3

এটি যদি সর্বজনীন এপিআই হয় তবে আপনার উত্তর দেওয়ার সময় আপনার রক্ষণশীল হওয়া উচিত, তবে উদারভাবে গ্রহণ করুন।

এর অর্থ আমার, আপনার 1 এবং 2 উভয়কে সমর্থন করা উচিত I

1 এবং 2 উভয়কে সমর্থন করার উপায় হ'ল অনুরোধ সংস্থায় যদি কোনও সরবরাহ না করা হয়, এবং যদি এটি অনুরোধ সংস্থায় থাকে তবে ইউআরএল থেকে আইডিটি পাওয়া যায়, তবে এটি ইউআরএল আইডিটির সাথে মেলে কিনা তা যাচাই করুন। যদি দুজনের মিল না হয়, তবে 400 টি খারাপ অনুরোধের প্রতিক্রিয়া ফিরিয়ে দিন।

কোনও ব্যক্তির রিসোর্স করার সময় রক্ষণশীল হতে হবে এবং সর্বদা আইডিকে জসসনে অন্তর্ভুক্ত করুন যদিও এটি পুটে .চ্ছিক।

Question 4

এই সমস্যার একটি সমাধানের মধ্যে "অ্যাপ্লিকেশন স্টেটের ইঞ্জিন হিসাবে হাইপারটেক্সট" বা "হেটোয়াস" কিছুটা বিভ্রান্তিকর ধারণা জড়িত। এর অর্থ হ'ল একটি REST প্রতিক্রিয়াতে হাইপারলিঙ্ক হিসাবে সম্পাদিত হওয়ার জন্য উপলব্ধ সংস্থান বা ক্রিয়া থাকে। এই পদ্ধতিটি ব্যবহার করে, যা আরইএসটি-র মূল ধারণার অংশ ছিল, স্বতন্ত্র অনন্য শনাক্তকারী / আইডিগুলি হ'ল হাইপারলিংক। সুতরাং, উদাহরণস্বরূপ, আপনার মতো কিছু থাকতে পারে:

GET /person/<UUID> {"person": {"location": "/person/<UUID>", "data": { "name": "Jimmy"}}}

তারপরে, আপনি যদি সেই সংস্থানটি আপডেট করতে চান তবে আপনি (সিউডোকোড) করতে পারেন:

updatedPerson = person.data
updatedPerson.name = "Timmy"
PUT(URI: response.resource, data: updatedPerson)

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

GET /people
{ "people": [
    "/person/1",
    "/person/2"
  ]
}

(আপনি অবশ্যই আবেদনের প্রয়োজনীয়তার উপর নির্ভর করে প্রতিটি ব্যক্তির জন্য পূর্ণ ব্যক্তি বস্তুটি ফিরিয়ে দিতে পারেন)।

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

Question 5

একটি সন্নিবেশে আপনার URL টিতে আইডি যুক্ত করার দরকার নেই। আপনি যদি কোনও পুটে আইডি প্রেরণ করেন তবে প্রাথমিক কী পরিবর্তন করতে আপনি আপডেট হিসাবে ব্যাখ্যা করতে পারেন।

সংস্থান:

PUT /persons/ 
  {"id": 1, "name": "Jimmy"}
HTTP/1.1 201 Created     
  {"id": 1, "name": "Jimmy", "other_field"="filled_by_server"}

GET /persons/1

HTTP/1.1 200 OK
  {"id": 1, "name": "Jimmy", "other_field"="filled_by_server"}

হালনাগাদ

PUT /persons/1 
     {"id": "2", "name": "Jimmy Jr"} - 
HTTP/1.1 200 OK
     {"id": "2", "name": "Jimmy Jr", "other_field"="filled_by_server"}

GET /persons/2 

HTTP/1.1 200 OK
     {"id": "2", "name": "Jimmy Jr", "other_field"="updated_by_server"}

তাদেরকে JSON এপিআই এই মান এবং সমাধান কিছু নতুন বস্তুর একটি লিঙ্ক সমেত সন্নিবেশিত বা আপডেট বস্তুর ফিরে বিষয় ব্যবহার করে। কিছু আপডেট বা সন্নিবেশগুলিতে এমন কিছু ব্যবসায়িক যুক্তি অন্তর্ভুক্ত থাকতে পারে যা অতিরিক্ত ক্ষেত্রগুলিকে পরিবর্তন করবে

আপনি সন্নিবেশ এবং আপডেটের পরে প্রাপ্তি এড়াতে পারবেন তাও দেখতে পাবেন।

Question 6

এটি আগে জিজ্ঞাসা করা হয়েছিল - আলোচনাটি দেখার মতো:

কোনও বিশ্রামের জিইটি প্রতিক্রিয়া কি কোনও সংস্থার আইডি ফিরিয়ে দেবে?

এটি সেই প্রশ্নগুলির মধ্যে একটি যেখানে এটি কী " বিতর্কিত " নয় এবং চারপাশে বিতর্কে জড়িয়ে থাকা সহজ where ।

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

Question 7

বিভিন্ন ক্রিয়াকলাপের জন্য আলাদা আলাদা উপস্থাপনা রাখা ঠিক আছে, তবে পুট এর জন্য একটি সাধারণ সুপারিশ হ'ল হোল পেওলড । তার মানে idসেখানেও হওয়া উচিত। অন্যথায়, আপনার প্যাচ ব্যবহার করা উচিত।

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

সুতরাং, আমরা কীভাবে এই জাতীয় সংঘাত সমাধান করব? আমাদের কাছে মূলত 2 টি বিকল্প রয়েছে:

একটি 4XX ব্যতিক্রম নিক্ষেপ করুন
একটি Warning( X-API-Warnইত্যাদি) শিরোনাম যুক্ত করুন।

আমি এই প্রশ্নের উত্তর পেতে যতটা কাছে পারি ততই কাছাকাছি কারণ সাধারণভাবে বিষয়টি একটি মতামতের বিষয়।

Question 8

বিভিন্ন পদ্ধতির ব্যবহারে খারাপ কিছু নেই। তবে আমি মনে করি সর্বোত্তম উপায় হ'ল ২ য় সমাধান ।

 PUT /person/UUID {"name": "Jimmy"}

 GET /person/UUID returns {"id": <UUID>, "name": "Jimmy"}

এটি সর্বাধিক এইভাবে ব্যবহৃত হয় এমনকি সত্তা কাঠামোটি এই কৌশলটি ব্যবহার করে যখন সত্তাটি ডিবি কনটেক্সটে যুক্ত করা হয় না উত্পন্ন আইডি ব্যতীত শ্রেণি আইডি সত্তা ফ্রেমওয়ার্কের রেফারেন্স দ্বারা উত্পন্ন হয়।

Question 9

আমি এটিকে JSON-LD / শব্দার্থক ওয়েব দৃষ্টিকোণ থেকে দেখছি কারণ এই স্লাইডগুলিতে আমি উল্লেখ করেছি বলেই সত্যিকারের বিশ্রামের কনফারেন্সটি অর্জন করার ভাল উপায় । সেই দৃষ্টিকোণ থেকে এটির দিকে তাকালে, কোনও ওয়েব সংস্থার আইডি (আইআরআই) সর্বদা ইউআরএলের সমান হওয়া উচিত যা আমি উত্সটি সন্ধান / অবলম্বন করতে ব্যবহার করতে পারি। আমি মনে করি যাচাইকরণ বাস্তবায়ন করা সত্যিই কঠিন নয় বা এটি গণনামূলকভাবে নিবিড়ও নয়; সুতরাং বিকল্পের সাথে যাওয়ার জন্য আমি এটিকে বৈধ কারণ হিসাবে বিবেচনা করি না (২)। আমি মনে করি বিকল্পটি (৩) আসলেই কোনও বিকল্প নয় কারণ পোস্ট (নতুন তৈরি করুন) এর তুলনায় পুট (আপডেট / প্রতিস্থাপন) এর চেয়ে আলাদা শব্দার্থবিজ্ঞান রয়েছে।

Question 10

শুধু এফওয়াইআই, উত্তরগুলি এখানে ভুল।

দেখা:

https://restfulapi.net/rest-api-design-tutorial-with-example/

https://restfulapi.net/rest-put-vs-post/

https://restfulapi.net/http-methods/#patch

পুট

বিদ্যমান রিসোর্স আপডেট করার জন্য প্রাথমিকভাবে PUT API গুলি ব্যবহার করুন (যদি সংস্থানটি বিদ্যমান না থাকে, তবে এপিআই কোনও নতুন সংস্থান তৈরি করার সিদ্ধান্ত নিতে পারে)। যদি পুট এপিআই দ্বারা একটি নতুন সংস্থান তৈরি করা হয়েছে, মূল সার্ভারটি HTTP প্রতিক্রিয়া কোড 201 (তৈরি) প্রতিক্রিয়াটির মাধ্যমে ব্যবহারকারী এজেন্টকে অবহিত করতে হবে এবং যদি কোনও বিদ্যমান সংস্থান পরিবর্তন করা হয় তবে 200 (ওকে) বা 204 (কোনও সামগ্রী নেই) প্রতিক্রিয়া কোডগুলি অনুরোধটির সফল সমাপ্তির ইঙ্গিত দিতে পাঠানো উচিত।

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

আপনি যখনই একক একক সংস্থানটি পরিবর্তন করতে চান যা ইতিমধ্যে সংস্থানগুলির অংশ is পুট পুরোপুরি রিসোর্সকে প্রতিস্থাপন করে। অনুরোধটি যদি সংস্থানটির অংশটি আপডেট করে তবে প্যাচ ব্যবহার করুন।

প্যাচ

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

সুতরাং আপনার এটি এইভাবে ব্যবহার করা উচিত:

POST    /device-management/devices      : Create a new device
PUT     /device-management/devices/{id} : Update the device information identified by "id"
PATCH   /device-management/devices/{id} : Partial-update the device information identified by "id"

বিশ্রামের অনুশীলনগুলি ইঙ্গিত দেয় যে আপনি / {id P এ কী রাখবেন তা বিবেচনা করা উচিত নয় - রেকর্ডের সামগ্রীটি পেলোডের সরবরাহকারীর সাথে আপডেট করা উচিত - তবে GET / {id still এখনও একই সংস্থানটিতে লিঙ্ক করা উচিত।

অন্য কথায়, পিইটি / 3 প্যালোড আইডি 4 এ আপডেট করতে পারে তবে জিইটি / 3 এখনও একই পেওলোডের সাথে লিঙ্ক করা উচিত (এবং আইডি সেটটি 4 এ প্রেরণ করবে)।

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

Question 11

আপনাকে প্যাচ / পুট অনুরোধের ধরণেরগুলি খতিয়ে দেখার দরকার হতে পারে।

প্যাচ অনুরোধগুলি কোনও সংস্থানটি আংশিকভাবে আপডেট করতে ব্যবহৃত হয় যেখানে PUT অনুরোধগুলিতে আপনাকে পুরো সংস্থানটি পাঠাতে হয় যেখানে এটি সার্ভারে ওভাররাইড হয়ে যায়।

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

আইডি সহ সার্ভারে কোনও উত্স আপডেট করার জন্য আপনি একটি প্যাচচ অনুরোধটি ব্যবহার করতে পারেন তবে এটি সনাক্ত করতে আসল আইডি আপডেট করবেন না।