বিশ্রামে পোষ্ট সাড়া দেওয়ার জন্য 'সেরা' অনুশীলন

Question

সুতরাং এখানে নতুন কিছু নয় আমি কেবল কিছু স্পষ্টতা নেওয়ার চেষ্টা করছি এবং অন্য পোস্টগুলিতে কোনও খুঁজে পাচ্ছে না বলে মনে হচ্ছে।

আমি অস্থিরভাবে একটি নতুন সংস্থান তৈরি করছি, বলুন:

/books (POST)

একটি শরীরের সাথে:

{
  title: 'The Lion, the Witch and the Wardrobe',
  author: 'C. S. Lewis'
}

আমি জানি যে নতুন সংস্থানটির অবস্থান শিরোনাম সহ আমার একটি 201 (তৈরি) করা উচিত:

Location: /books/12345

আমি নিজের কাছে যে প্রশ্নের উত্তর দিতে পারি না বলে মনে হচ্ছে তা হ'ল সার্ভারের শরীরে কী ফিরে আসা উচিত।

আমি প্রায়শই এই ধরণের প্রতিক্রিয়াটি করেছি:

{
  id: 12345,
  title: 'The Lion, the Witch and the Wardrobe',
  author: 'C. S. Lewis'
}

আমি বেশ কয়েকটি কারণে এটি করেছি:

1. আমি অ্যাংুলারজগুলির মতো ফ্রন্ট এন্ড ফ্রেমওয়ার্কগুলির জন্য এপি লিখেছি। আমার বিশেষ ক্ষেত্রে আমি কৌনিক সংস্থান ব্যবহার করছি এবং উত্সটি সনাক্ত করতে আমার প্রায়শই কেবল আইডি প্রয়োজন। আমি যদি প্রতিক্রিয়া সংস্থায় আইডিটি না ফেরান তবে আমার অবস্থান শিরোনামের বাইরে পার্স করা দরকার।
2. সমস্ত বইয়ের একটি জিইটি-তে আমি সাধারণত পুরো আইটেমটি কেবল আইডি না দিয়ে ফিরিয়ে দিই। এই অর্থে আমার ক্লায়েন্ট কোডে আইডিটি কোথায় পাবেন (অবস্থান শিরোনাম বা বডি) আলাদা করতে হবে না।

এখন আমি জানি আমি সত্যিই এখানে ধূসর অঞ্চলে আছি, তবে বেশিরভাগ লোকেরা বলছেন যে পুরো সম্পদ ফিরিয়ে দেওয়া 'খারাপ' অনুশীলন। তবে কী যদি সার্ভারটি পরিবর্তনে / সংস্থানটিতে তথ্য যুক্ত করে। এটি অবশ্যই আইডি যুক্ত করে তবে টাইমস্ট্যাম্পের মতো অন্যান্য জিনিসও যুক্ত করতে পারে। আমি পুরো রিসোর্সটি ফিরিয়ে দিচ্ছি না সে ক্ষেত্রে কোনও পোস্ট করা, আইডি ফিরিয়ে দেওয়া কী ক্লায়েন্টকে নতুন রিসোর্স পাওয়ার জন্য জিইটি সম্পাদন করা ভাল?

Comments

আমি ব্যক্তিগতভাবে পোস্ট পোস্টের প্রতিক্রিয়াগুলির জন্য খালি শরীর পছন্দ করি। RESTful অবস্থানের শিরোনাম মানটি কোনও ইউআরআই (অনন্য সংস্থান সনাক্তকারী) হওয়া উচিত নয়? সুতরাং সম্ভবত আপনার কোনও আইডি হিসাবে এটি ব্যবহার করা উচিত এবং কোনও সার্ভারের অভ্যন্তরীণ আইডি বের করার জন্য এটি পার্স করা উচিত নয়। IMO, RESTful API গ্রাহকরা হাইপারলিংকগুলি সরবরাহ করে এবং পথ তৈরি না করে নেভিগেট করা উচিত, অনুমান করে কোনও নির্দিষ্ট সার্ভার কোথায় সংস্থানগুলি সন্ধান করে ... এবং সর্বোপরি, ক্লায়েন্টটি ইতিমধ্যে এটি তৈরি করা সংস্থার অবস্থাটি কি জানেন না? এটিকে পুনরাবৃত্তি করা নেটওয়ার্ক সংস্থানগুলির অপচয়কে সিল করে।

— ch4mp

তৈরি / সন্নিবেশ করার জন্য, স্ট্যাটাস 201 - তৈরি করা হয়েছে, শিরোনামের অবস্থান → লোকালহোস্ট: 8080 / কর্মচারী / 1 (দেখুন: এখানে )

— হাসান তারেক

Answer 1

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

আপনার প্রাথমিক পোস্টটি দিয়ে আপনি যে তথ্য পেতে পারতেন তা পেতে কেবলমাত্র আইডি ফিরিয়ে দেওয়া এবং পরে একটি জিইটি অনুরোধ করার কোনও সুযোগ আমি দেখতে পাচ্ছি না।

যাইহোক, আপনার API যতক্ষণ না সামঞ্জস্যপূর্ণ আমি মনে করি আপনার প্যাটার্নটি বেছে নেওয়া উচিত যা আপনার প্রয়োজনের সাথে সবচেয়ে ভাল ফিট করে। ইমো, আরইএসটি এপিআই কীভাবে তৈরি করবেন তার কোনও সঠিক উপায় নেই।

Comments

আমি জানি এটি পুরানো, তবে আমি আপনার পোষ্টের পরে জিইটি ব্যবহারের জন্য একটি দৃing়প্রত্যয়ী যুক্তি দিতে পারি। HTTP / 1.1 স্পেসে কোনও historicalতিহাসিক সরঞ্জাম আপনার GET প্রতিক্রিয়া থেকে ফিরে আসা ক্যাশে সেটিংসটিকে উপেক্ষা করতে পারে ... সুতরাং আপনি যদি পোস্টার দিয়ে আপডেট করার পরে আপনার ব্যবহারকারী এই পৃষ্ঠায় ফিরে যেতে ব্রাউজারের পিছনের বোতামটি ব্যবহার করেন তবে এটি বাসি ব্যবহার করতে পারে মূল জিইটি থেকে ডেটা ক্যাশে করা হয়েছে। সুতরাং আপনি যদি জিইটি পুনরায় ব্যবহার করেন তবে আপনি ক্যাশেটি আপডেট করতে পারেন এবং

— শেড

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

— জীহুত

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

— ফ্রেণ্ডেভেল

Answer 2

নতুন বস্তুটি ফিরিয়ে দেওয়া "ইউনিফর্ম ইন্টারফেস - উপস্থাপনার মাধ্যমে সংস্থানসমূহের হেরফের" এর REST নীতিটির সাথে খাপ খায়। সম্পূর্ণ বস্তুটি তৈরি করা বস্তুর নতুন অবস্থার প্রতিনিধিত্ব।

এপিআই ডিজাইনের জন্য এখানে একটি দুর্দান্ত রেফারেন্স রয়েছে: একটি প্র্যাকমেটিক RESTful এপিআই ডিজাইনের সেরা অভ্যাস

এটিতে এখানে আপনার প্রশ্নের উত্তর অন্তর্ভুক্ত রয়েছে: আপডেট এবং তৈরির কোনও উত্সের উপস্থাপনা ফিরে আসা উচিত

এটা বলে:

কোনও আপডেট উপস্থাপনের জন্য কোনও এপিআই গ্রাহককে আবার এপিআইতে আঘাত হানা থেকে বাঁচতে, এপিআইকে প্রতিক্রিয়ার অংশ হিসাবে আপডেট (বা তৈরি করা) উপস্থাপনাটি ফিরিয়ে দিন।

আমার কাছে সুন্দরভাবে বাস্তববাদী বলে মনে হচ্ছে এবং এটি উপরে উল্লিখিত সেই বিশ্রাম নীতিটির সাথে খাপ খায়।

Comments

কীভাবে প্রাসঙ্গিক সামগ্রীর পুরো সেটটি ফেরত দেবেন? এইভাবে, সম্ভাব্য বাছাই সার্ভার-সাইড করা যেতে পারে, এবং এটি ফ্রন্ট-এন্ড বাস্তবায়নকে সহজ করে

— phil294

তবে এই সেরা অনুশীলনগুলি সেরা নয়। লেখক বলেছেন যে হেটোয়াস, যা অন্যান্য নীতিগুলির মতো গুরুত্বপূর্ণ, অবশ্যই ব্যবহার করা উচিত নয় কারণ "এটি প্রস্তুত নয়"। HETOAS কখনই "প্রস্তুত" হবে না, কারণ সমস্ত RESTful নীতিগুলি কেবল স্থাপত্য নকশার নীতি, নির্দিষ্ট প্রয়োগ নয়। উদ্ধৃত রেফারেন্সটি RESTful এপিআই সম্পর্কে লেখকের দৃষ্টিভঙ্গি সম্পর্কে, যা HATEOAS বাদ দেওয়ার কারণে মোটেও বিশ্রামযোগ্য নয়। এই কারণেই এটি সর্বোত্তম রেফারেন্স নয় :)

— মার্চিন

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

— গ্রাহামসেড

@ গ্রাহামসিড একটি বাস্তবায়ন একটি পৃথক বিষয় যা স্থাপত্য নকশা প্রিপিসল / প্যাটার্ন। কেউ আশা করতে পারে না যে হেটোয়াস কোনও দিন প্রস্তুত থাকবে, তবে এমন সুযোগ রয়েছে যে কেউ একটি বাস্তবায়ন তৈরি করবেন যা অনেকের দ্বারা গ্রহণযোগ্য। বিনয় ইউআরএল এবং সুনির্দিষ্ট ক্রিয়াকলাপগুলিতে (সিআরইউডি) HTTP পদ্ধতিগুলি ম্যাপিং সম্পর্কেও লিখেছেন, ইউআরএলগুলির উপসর্গ দ্বারা সংস্করণ করা আরও বাস্তববাদী, লিখেছেন যে ক্যোয়ারী প্যারামিটারগুলি দ্বারা ফিল্টারিং করা একটি উপায় যা ... এটি ঠিক আছে, তবে এর সব কিছুই কম নয় RESTful আর্কিটেকচার দিয়ে না। তিনি একরকম চুক্তি সম্পর্কে লিখেছিলেন। এটি HTTP এপিআই-এর পক্ষে ঠিক আছে তবে এটিকে বিশ্রামের মতো বলবেন না।

— মার্সিন

-: এখানে @grahamesd কিছু এই ব্যাখ্যা পোস্ট আছে medium.com/@andrea.chiarelli/... - restfulapi.net

— marcinn