REST এপিআই ডিজাইন - বিভিন্ন পরামিতি তবে একই url প্যাটার্ন সহ REST এর মাধ্যমে একটি সংস্থান প্রাপ্ত

Question 1

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

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

এই অনুশীলনটি কোনও বইয়ে এবং কোথাও স্ট্যাকওভারফ্লোতে পড়ুন (আমি আবার লিঙ্কটি খুঁজে পাচ্ছি না)

GET /users/id={id}
GET /users/email={email}

এই অনুশীলনটি প্রচুর ব্লগে পড়ুন

GET /users/{id}
GET /users/email/{email}

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

GET /users?id={id}
GET /users?email={email}

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

সমস্ত সাহায্য প্রশংসা!

Question 2

আমার অভিজ্ঞতা, GET /users/{id} GET /users/email/{email}সবচেয়ে সাধারণ পদ্ধতির হয়। আমিও আশা করব যে পদ্ধতিগুলি সরবরাহকারীর সাথে idবা যদি উপস্থিত না থাকলে 404 পাওয়া যায়নি ফিরে আসবে email। আমি অবাক হয়ে দেখব না GET /users/id/{id}, হয় হয় (যদিও আমার মতে এটি অপ্রয়োজনীয়)।

অন্যান্য পদ্ধতির উপর মন্তব্য

GET /users/id={id} GET /users/email={email}
- আমি মনে করি না যে আমি এটি দেখেছি, এবং যদি আমি এটি দেখতে পেতাম তবে এটি খুব বিভ্রান্তিকর হবে। এটি প্রায় যেমন পথের পরামিতিগুলির সাথে ক্যোয়ারী প্যারামিটারগুলি অনুকরণ করার চেষ্টা করছে।
GET /users?id={id} GET /users?email={email}
- আমি মনে করি আপনি ফিল্টারিংয়ের জন্য ক্যোয়ারী প্যারামিটার ব্যবহার করার সময় আপনি মাথায় পেরেকটি আঘাত করেছিলেন।
- এই রিসোর্সটিকে একটি এবং একটি (উদাহরণস্বরূপ ) উভয় দিয়ে কল করা কি কখনও বোঝা যাবে ? যদি তা না হয় তবে আমি এর মতো কোনও একক সংস্থান পদ্ধতি ব্যবহার করব না।idemailGET /users?id={id}&email={email}
- আমি একটি পুনরুদ্ধারের জন্য এই পদ্ধতি আশা তালিকা ফিল্টারিং জন্য ঐচ্ছিক ক্যোয়ারী পরামিতি সঙ্গে ব্যবহারকারীদের, কিন্তু আমি আশা করবেন না id, emailবা কোনো অনন্য শনাক্তকারী পরামিতি মধ্যে যাবে। উদাহরণস্বরূপ: GET /users?status=BANNEDনিষিদ্ধ ব্যবহারকারীদের একটি তালিকা ফিরে আসতে পারে।

_{সম্পর্কিত উত্তর থেকে এই উত্তরটি দেখুন ।}

Question 3

এই ব্যবহারিকভাবে তাকান, আপনি ব্যবহারকারীর একটি সংগ্রহ পেয়েছেন:

/users   # this returns many

প্রতিটি ব্যবহারকারীর একটি উত্সর্গীকৃত সংস্থান অবস্থান:

/users/{id}    # this returns one

আপনি ব্যবহারকারীদের অনুসন্ধানের বিভিন্ন উপায় পেয়েছেন:

/users?email={email}
/users?name=*bob*

যেহেতু এগুলি / ব্যবহারকারীর কাছে সমস্ত ক্যোয়ারী প্যারামিটার, তাই তাদের সমস্ত তালিকাটি ফেরত দেওয়া উচিত ... এটি 1 টির তালিকা থাকলেও।

আমি এখানে প্র্যাকমেটিক রিস্টালফুল এপিআই নকশায় একটি ব্লগ পোস্ট লিখেছিলাম যা এখানে অন্যান্য বিষয়গুলির সাথে এখানে এই বিষয়ে কথা বলেছে: http://www.vinaysahni.com/best-practices-for-a-pragmatic-restful-api

Question 4

ব্যবহারকারীর সংস্থান সম্পর্কে

পথে /usersআপনি সর্বদা ফিরে আসা ব্যবহারকারী সংস্থার সংগ্রহ পাবেন get

পথে /users/[user_id]আপনি বেশ কয়েকটি কি ঘটতে পারে তা আশা করতে পারেন:

আপনার আইডেন্টিফায়ার [ইউজার_আইডি] বা ব্যবহারকারীর সংস্থানটি উপস্থাপন করে এমন একক সংস্থান পাওয়া উচিত
আইডি [ইউজার_আইডি] সহ কোনও ব্যবহারকারী উপস্থিত না থাকলে বা 404 টির সাড়া পাওয়া যায় নি
যদি আপনাকে অনুরোধ করা ব্যবহারকারীর সংস্থান অ্যাক্সেস করার অনুমতি না দেওয়া হয় তবে একটি নিষিদ্ধ 401

প্রতিটি সিঙ্গলটন তার পথ এবং সনাক্তকারী দ্বারা স্বতন্ত্রভাবে চিহ্নিত হয় এবং আপনি এগুলি সংস্থানটি সন্ধান করতে ব্যবহার করেন। সিঙ্গলটনের জন্য বেশ কয়েকটি পথ ব্যবহার করা সম্ভব নয়।

আপনি /usersক্যোয়ারী প্যারামিটারগুলি ( GETপরামিতি) দিয়ে পাথটি জিজ্ঞাসা করতে পারেন । এটি অনুরোধের মানদণ্ড পূরণকারী ব্যবহারকারীদের সাথে একটি সংগ্রহ ফিরিয়ে দেবে। ফিরে আসা সংগ্রহটিতে ব্যবহারকারীর সংস্থান থাকতে হবে, প্রতিক্রিয়াতে তাদের সনাক্তকরণের সংস্থান পথ সহ all

প্যারামিটারগুলি সংগ্রহের সংস্থানগুলিতে যে কোনও ক্ষেত্র থাকতে পারে; firstName, lastName,id

ইমেল সম্পর্কে

ইমেলটি কোনও সংস্থান বা ব্যবহারকারীর সংস্থার সম্পত্তি / ক্ষেত্র হতে পারে।

- ব্যবহারকারীর সম্পত্তি হিসাবে ইমেল:

ক্ষেত্রটি যদি ব্যবহারকারীর সম্পত্তি হয় তবে ব্যবহারকারীর প্রতিক্রিয়াটি এরকম কিছু দেখায়:

{ 
  id: 1,
  firstName: 'John'
  lastName: 'Doe'
  email: 'john.doe@example.com'
  ...
}

এই মানে ইমেল করার জন্য কোন বিশেষ শেষবিন্দু, কিন্তু আপনি এখন নিম্নলিখিত অনুরোধ পাঠিয়ে তার ইমেল দ্বারা একটি ব্যবহারকারী পেতে পারবেন: /users?email=john.doe@example.com। কোনটি (ধরে নেওয়া ইমেলগুলি ব্যবহারকারীদের কাছে অনন্য) ইমেলটির সাথে মেলে এমন একটি ব্যবহারকারীর আইটেমের সাথে একটি সংগ্রহ ফিরিয়ে আনবে।

- একটি উত্স হিসাবে ইমেল:

তবে যদি ব্যবহারকারীদের ইমেলগুলিও সম্পদ হয়। তারপরে আপনি এমন একটি এপিআই তৈরি করতে পারেন যেখানে /users/[user_id]/emailsআইডির সাথে ব্যবহারকারীর জন্য ইমেল ঠিকানাগুলির সংগ্রহ ফেরত দেয় user_id। /users/[user_id]/emails/[email_id]ব্যবহারকারী_আইডি এবং ['ইমেল_আইডি'] এর সাথে ব্যবহারকারীর ইমেল ফেরত দেয়। আপনি সনাক্তকারী হিসাবে যা ব্যবহার করেন তা আপনার উপর নির্ভর করে তবে আমি একটি পূর্ণসংখ্যায় আটকে থাকব। আপনি DELETEযে ইমেলটি মুছতে চান তা চিহ্নিত করার পথে আপনি একটি অনুরোধ প্রেরণ করে আপনি ব্যবহারকারীর কাছ থেকে একটি ইমেল মুছতে পারেন । উদাহরণস্বরূপ সুতরাং DELETEউপর /users/[user_id]/emails/[email_id]email_id যে USER_ID ব্যবহারকারীর মালিকানাধীন হয় সহ ইমেল মুছে ফেলবে। সম্ভবত সম্ভবত সেই ব্যবহারকারীকেই এই মোছা অপারেশন সম্পাদনের অনুমতি দেওয়া হয়। অন্যান্য ব্যবহারকারীরা 401 প্রতিক্রিয়া পাবেন।

যদি কোনও ব্যবহারকারীর কেবল একটি ইমেল ঠিকানা থাকে তবে আপনি আটকে থাকতে পারেন /users/[user_id]/email এটি একটি সিঙ্গলটন সংস্থান দেয়। ব্যবহারকারী PUTসেই url এ ইমেল ঠিকানা টাই করে তার ইমেল ঠিকানা আপডেট করতে পারে ।