কীভাবে RESTful অনুসন্ধান / ফিল্টারিং ডিজাইন করবেন? [বন্ধ]

455

বন্ধ । এই প্রশ্নটি মতামত ভিত্তিক । এটি বর্তমানে উত্তর গ্রহণ করছে না।

এই প্রশ্নটি উন্নত করতে চান? প্রশ্নটি আপডেট করুন যাতে পোস্টটি সম্পাদনা করে সত্য এবং উদ্ধৃতি দিয়ে উত্তর দেওয়া যায় ।

2 বছর আগে বন্ধ ।

আমি বর্তমানে পিএইচপি-তে একটি RESTful এপিআই ডিজাইন এবং প্রয়োগ করছি। তবে আমি আমার প্রাথমিক নকশা বাস্তবায়নে ব্যর্থ হয়েছি।

GET /users # list of users
GET /user/1 # get user with id 1
POST /user # create new user
PUT /user/1 # modify user with id 1
DELETE /user/1 # delete user with id 1

এখন পর্যন্ত বেশ মান, তাই না?

আমার সমস্যা প্রথমটি নিয়ে GET /users। আমি তালিকাটি ফিল্টার করার জন্য অনুরোধের বরাতে প্যারামিটারগুলি পাঠানোর বিষয়ে বিবেচনা করছি। এটি কারণ যে আমি একটি দীর্ঘ দীর্ঘ url না পেয়ে জটিল ফিল্টার নির্দিষ্ট করতে সক্ষম হতে চাই, যেমন:

GET /users?parameter1=value1&parameter2=value2&parameter3=value3&parameter4=value4

পরিবর্তে আমি কিছু চাই:

GET /users
# Request body:
{
    "parameter1": "value1",
    "parameter2": "value2",
    "parameter3": "value3",
    "parameter4": "value4"
}

যা অনেক বেশি পঠনযোগ্য এবং জটিল ফিল্টার সেট করার দুর্দান্ত সম্ভাবনা দেয়।

যাইহোক, অনুরোধগুলির file_get_contents('php://input')জন্য GETঅনুরোধের বডিটি ফেরত দেয় না । আমি চেষ্টাও করেছিলাম http_get_request_body(), তবে যে শেয়ারিং হোস্টিংটি ব্যবহার করছি সেটি নেই pecl_http। নিশ্চিত নয় যে এটি যেভাবেই সহায়তা করেছিল।

আমি এই প্রশ্নটি পেয়েছি এবং বুঝতে পেরেছি যে জিইটি সম্ভবত একটি অনুরোধের বৌ থাকার কথা নয়। এটি কিছুটা অনির্বাচিত ছিল তবে তারা এর বিরুদ্ধে পরামর্শ দিয়েছে।

তাই এখন আমি কী করব তা নিশ্চিত নই। আপনি কীভাবে একটি রেস্টস্টুল অনুসন্ধান / ফিল্টারিং ফাংশন ডিজাইন করেন?

আমি মনে করি আমি ব্যবহার করতে পারি POST, তবে এটি খুব বিশ্রামজনক বলে মনে হচ্ছে না।

— এরিক বি
সূত্র

7

অনুসন্ধানের জন্য

— আরএসএফুল

60

সাবধান হও!!! GET পদ্ধতিটি অবশ্যই আইডেম্পোটেন্ট হতে হবে এবং অবশ্যই "ক্যাশেযোগ্য" হতে হবে। আপনি যদি শরীরে তথ্য প্রেরণ করেন তবে কীভাবে সিস্টেম আপনার অনুরোধটিকে ক্যাশে করতে পারে? এইচটিটিপি অনুরোধের অংশ নয়, কেবল ইউআরএল ব্যবহার করে জিইটি অনুরোধের ক্যাচিংয়ের অনুমতি দেয়। উদাহরণস্বরূপ, এই দুটি অনুরোধ: উদাহরণ. com {পরীক্ষা: "কিছু"} উদাহরণ. com {আরেকটি টেস্ট: "কিছু 2" কে ক্যাশে সিস্টেম দ্বারা একই হিসাবে বিবেচনা করা হয়: তাদের উভয়ের ঠিক একই URL রয়েছে

— jfcorugedo

15

কেবল যোগ করার জন্য, আপনার / ব্যবহারকারীদের (সংগ্রহ) এবং ইউজারের (একক ব্যবহারকারীর) কাছে পোস্ট করা উচিত।

— ম্লাদেন বি।

1

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

— ব্যবহারকারী3206144

2

অনুসন্ধানের জন্য

— আরএসএসএল

397

একটি রিস্টলফুল অনুসন্ধান কার্যকর করার সর্বোত্তম উপায় হ'ল অনুসন্ধানটিকে নিজেকে একটি উত্স হিসাবে বিবেচনা করা। তারপরে আপনি POST ক্রিয়াটি ব্যবহার করতে পারেন কারণ আপনি একটি অনুসন্ধান তৈরি করছেন। একটি পোষ্ট ব্যবহার করতে আপনাকে আক্ষরিক অর্থে একটি ডাটাবেসে কিছু তৈরি করতে হবে না।

উদাহরণ স্বরূপ:

Accept: application/json
Content-Type: application/json
POST http://example.com/people/searches
{
  "terms": {
    "ssn": "123456789"
  },
  "order": { ... },
  ...
}

আপনি ব্যবহারকারীর দৃষ্টিকোণ থেকে একটি অনুসন্ধান তৈরি করছেন। এর বাস্তবায়ন বিবরণ অপ্রাসঙ্গিক। কিছু RESTful API গুলি এমনকি অধ্যবসায়ের দরকারও পড়তে পারে না। এটি একটি বাস্তবায়ন বিশদ।

— জেসন হ্যারেলসন
সূত্র

209

অনুসন্ধানের শেষ পয়েন্টের জন্য একটি পোষ্ট অনুরোধ ব্যবহারের জন্য একটি উল্লেখযোগ্য সীমাবদ্ধতা হ'ল এটি বুকমার্ক করা যায় না। বুকমার্কিং অনুসন্ধানের ফলাফলগুলি (বিশেষত জটিল প্রশ্নগুলি) বেশ কার্যকর হতে পারে।

— কাউচাঁদ

73

অনুসন্ধানগুলি করতে POST ব্যবহার করা বিশ্রামের ক্যাশে সীমাবদ্ধতা ভঙ্গ করতে পারে। whatisrest.com/rest_constraints/cache_excerps

— ফিলিপ

55

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

— sleblanc

32

আমার মনে হয় না যে পোস্টটি অনুসন্ধানের জন্য উপযুক্ত পদ্ধতি, সাধারণ জিইটি অনুরোধের ডেটা সময়ের সাথে সাথে আলাদাও হতে পারে।

— আশ্চর্য

82

এটি একেবারে সবচেয়ে খারাপ সম্ভাব্য উত্তর। আমি বিশ্বাস করতে পারি না এটির এতগুলি উত্সাহ রয়েছে। এই উত্তরটি কেন ব্যাখ্যা করেছে: প্রোগ্রামার্স.স্ট্যাকেক্সেঞ্জার

— 233164/…

141

আপনি যদি জিইটি অনুরোধে অনুরোধের বডিটি ব্যবহার করেন তবে আপনি আরইএসটি নীতিটি ভঙ্গ করছেন, কারণ আপনার জিইটি অনুরোধটি ক্যাশে হতে সক্ষম হবে না, কারণ ক্যাশে সিস্টেমটি কেবলমাত্র ইউআরএল ব্যবহার করে।

এবং সবচেয়ে খারাপ, আপনার ইউআরএল বুকমার্ক করা যাবে না, কারণ URL এ এই পৃষ্ঠায় ব্যবহারকারীকে পুনঃনির্দেশ করার জন্য প্রয়োজনীয় সমস্ত তথ্য নেই

অনুরোধের বডি প্যারামিটারের পরিবর্তে ইউআরএল বা ক্যোয়ারি প্যারামিটার ব্যবহার করুন।

উদাহরণ:

/myapp?var1=xxxx&var2=xxxx
/myapp;var1=xxxx/resource;var2=xxxx

আসলে, এইচটিটিপি আরএফসি 7231 বলছে যে:

একটি জিইটি অনুরোধ বার্তার মধ্যে একটি পেডের কোনও নির্ধারিত শব্দার্থবিজ্ঞান নেই; একটি জিইটি অনুরোধে পে-লোড বডি প্রেরণের ফলে কিছু বিদ্যমান বাস্তবায়ন অনুরোধটিকে প্রত্যাখ্যান করতে পারে।

আরও তথ্যের জন্য কটাক্ষপাত করা এখানে

— jfcorugedo
সূত্র

29

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

— জেক

2

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

— ড্যানিয়েল লরেঞ্জ 17

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

— নাথান

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

— ড্যানিয়েল লরেঞ্জ

@ ড্যানিয়েললরেঞ্জ আহ ঠিক আছে তা বোঝা যায়। আমি মনে করি আপনি যা বলছিলেন তা আমি ভুল বুঝেছি।

— নাথন

70

মনে হচ্ছে রিসোর্স ফিল্টারিং / অনুসন্ধান একটি বিশ্রামের উপায়ে প্রয়োগ করা যেতে পারে। ধারণাটি হ'ল একটি নতুন এন্ডপয়েন্ট উপস্থাপন করা /filters/বা /api/filters/।

এই শেষ পয়েন্ট ফিল্টারটি ব্যবহার করা একটি উত্স হিসাবে বিবেচনা করা যায় এবং তাই POSTপদ্ধতির মাধ্যমে তৈরি করা হয় । এই ভাবে - অবশ্যই - শরীরকে সমস্ত পরামিতি বহন করতে ব্যবহার করা যেতে পারে পাশাপাশি জটিল অনুসন্ধান / ফিল্টার কাঠামো তৈরি করা যায়।

এই ধরনের ফিল্টার তৈরির পরে অনুসন্ধান / ফিল্টার ফলাফল পাওয়ার দুটি সম্ভাবনা রয়েছে।

অনন্য আইডি সহ একটি নতুন সংস্থান 201 Createdস্থিতি কোড সহ ফিরে আসবে । তারপরে এই আইডিটি ব্যবহার করে একটি GETঅনুরোধ করা যেতে পারে /api/users/:
```
GET /api/users/?filterId=1234-abcd
```
পরে নতুন ফিল্টার মাধ্যমে তৈরি করা হয় POSTএটি দিয়ে উত্তর দেব না 201 Createdকিন্তু একবার সময়ে 303 SeeOtherসহ Locationহেডার নির্দেশ করে /api/users/?filterId=1234-abcd। অন্তর্নিহিত লাইব্রেরির মাধ্যমে এই পুনঃনির্দেশটি স্বয়ংক্রিয়ভাবে পরিচালিত হবে।

উভয় পরিস্থিতিতে ফিল্টার করা ফলাফল পেতে দুটি অনুরোধ করা দরকার - এটি একটি অপূর্ণতা হিসাবে বিবেচিত হতে পারে, বিশেষত মোবাইল অ্যাপ্লিকেশনগুলির জন্য। মোবাইল অ্যাপ্লিকেশনগুলির জন্য আমি একক POSTকল ব্যবহার করব /api/users/filter/।

কিভাবে তৈরি ফিল্টার রাখবেন?

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

এই ধারণার সুবিধা কি?

ফিল্টার, ফিল্টার করা ফলাফল ক্যাশেযোগ্য এবং এমনকি বুকমার্ক করা যায়।

— উপল
সূত্র

2

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

— দান্তেবারবা

2

এই পদ্ধতির সাথে একমাত্র উদ্বেগ হ'ল, যদি আপনার ক্যোয়ারিতে তারিখ-সময় ফিল্টার থাকে (বা ক্রমাগত পরিবর্তিত মান)। তারপরে ডিবিতে (বা ক্যাশে) সংরক্ষণের জন্য ফিল্টার সংখ্যা অসংখ্য are

— আরভি পান্ডে

17

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

কনভেনশন অনুসারে, যখন জিইটি পদ্ধতি ব্যবহার করা হয়, তখন উত্স সনাক্ত করতে প্রয়োজনীয় সমস্ত তথ্য ইউআরআইতে এনকোড করা থাকে। নিরাপদ মিথস্ক্রিয়তার জন্য HTTP / 1.1 তে কোনও কনভেনশন নেই (যেমন, পুনরুদ্ধার) যেখানে ক্লায়েন্টটি কোনও ইউআরআইয়ের কোয়েরি অংশের পরিবর্তে এইচটিটিপি সত্তা সংস্থাতে সার্ভারে ডেটা সরবরাহ করে। এর অর্থ নিরাপদ অপারেশনের জন্য ইউআরআই দীর্ঘ হতে পারে।

— Daff
সূত্র

5

ইলাস্টিক অনুসন্ধান এছাড়াও শরীরের সাথে জিইটি করে এবং ভাল কাজ করে!

— তরুণ সাপরা

হ্যাঁ তবে তারা সার্ভার বাস্তবায়ন নিয়ন্ত্রণ করে আন্তঃবিশ্বগুলিতে টেন জেস নাও।

— ব্যবহারকারীর 432024

7

আমি যখন ল্যারাভেল / পিএইচপি ব্যাকএন্ড ব্যবহার করছি তখন আমি এরকম কিছু নিয়ে যেতে ঝোঁক:

/resource?filters[status_id]=1&filters[city]=Sydney&page=2&include=relatedResource

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

আপনি যদি অন্য ভাষা ব্যবহার করেন তবে এটি এখনও একটি ভাল কনভেনশন হতে পারে এবং আপনি []অ্যারেতে রূপান্তর করতে পার্সার তৈরি করতে পারেন ।

— একটি-ট্রেন
সূত্র

এই পদ্ধতিরটি দেখতে দুর্দান্ত দেখাচ্ছে, তবে ইউআরএলগুলিতে বর্গক্ষেত্র বন্ধনী ব্যবহার করার ক্ষেত্রে সমস্যা থাকতে পারে, ইউআরএল -এ-ব্যবহার করতে পারেন-অক্ষরগুলি

— স্কাই

2

@ স্কাই ইউআরআই [এবং এনকোডিং দ্বারা এড়ানো যেতে পারে ]। গ্রুপ ক্যোয়ারী প্যারামিটারগুলিতে এই অক্ষরগুলির এনকোড উপস্থাপনা ব্যবহার করা একটি সুপরিচিত অনুশীলন। এমনকি এটি JSON: এপিআই স্পেসিফিকেশনে ব্যবহৃত হয় ।

— jelhan

6

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

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

.ie। স্টোর # 1 (1, মান 2, মান 3, ... ইউআরআই ক্যোয়ারী প্যারামিটারগুলির জন্য একটি শর্টহ্যান্ড হিসাবে) স্টোর # 1 এ i = 1..4 এর জন্য "ব্যবহারকারী" প্রকারের অনুসন্ধান করুন [i] = মান [i]

1) GET /store1/search/user/value1,value2,value3,value4

অথবা

2) GET /store1/search/user,value1,value2,value3,value4

বা নিম্নলিখিত হিসাবে (যদিও আমি এটির সুপারিশ করব না, এরপরে আরও)

3) GET /search/store1,user,value1,value2,value3,value4

বিকল্প 1 সহ, আপনি /store1/search/userস্টোর 1 এর অধীনে সংস্থানগুলির অনুসন্ধানের জন্য ডিফল্টরূপে অনুসন্ধানের হ্যান্ডলারের সাথে পূর্বনির্ধারিত সমস্ত ইউআরআই মানচিত্র করুন (বা যে কোনও পিএইচপি উপাধি)/search?location=store1&type=user ।

কনভেনশন দ্বারা ডকুমেন্টেড এবং এপিআই দ্বারা প্রয়োগ করা হয়, 1 থেকে 4 পরামিতির মানগুলি কমা দ্বারা আলাদা করা হয় এবং সেই ক্রমে উপস্থাপন করা হয়।

বিকল্প 2 অনুসন্ধান প্রকার যুক্ত করে (এই ক্ষেত্রে user ) অবস্থানগত প্যারামিটার # 1 হিসাবে যুক্ত করে। হয় বিকল্প কেবল একটি প্রসাধনী পছন্দ।

বিকল্প 3টিও সম্ভব, তবে আমি এটি পছন্দ করব বলে মনে করি না। আমি মনে করি সন্ধানের আগেই ইউআরআইতে নির্দিষ্ট সংস্থানগুলির মধ্যে অনুসন্ধানের দক্ষতা উপস্থাপন করা উচিত (যেন ইউআরআই-তে স্পষ্টভাবে ইঙ্গিত দেওয়া হয় যে সন্ধানটি উত্সের মধ্যে সুনির্দিষ্ট।)

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

আপনি যখন এ জাতীয় কিছু করেন, আপনি জিইটি ব্যবহার করতে পারেন, এবং এটি কেবল পঠনযোগ্য সংস্থান হবে (যেহেতু আপনি এটি পোস্ট বা পুট করতে পারবেন না - এটি পাওয়ার পরে এটি আপডেট হয়ে যায়)। এটি এমন একটি উত্স হবে যা কেবলমাত্র যখন অনুরোধ করা হয় তখনই তা উপস্থিত হয়।

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

আপনি এটি সম্পর্কে কীভাবে যাবেন সেটি একটি ডিজাইনের সিদ্ধান্ত হবে, তবে আমি যাব। এটি নিখুঁত নয় এবং আমি নিশ্চিত যে এমন কেসগুলি হবে যেখানে এটি করা সবচেয়ে ভাল জিনিস নয় (বিশেষত খুব জটিল অনুসন্ধানের মানদণ্ডের জন্য)।

— luis.espinal
সূত্র

7

হ্যাঁ, যদি আপনি (কেউ, যে কেউ / যাই হোক না কেন) আমার উত্তরকে নীচে নামিয়ে আনার জন্য জিনিসগুলি লেখেন, তবে কি কমপক্ষে কোনও মন্তব্য করাতে আপনি অহংকে আঘাত করবেন? আমি জানি এটি ইন্টারভিউজ, কিন্তু ...;)

— লুইস.এসপাইনাল

107

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

— gardarh

14

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

— স্টিভেন হেরোড 5

14

@ গড়দাড় - হ্যাঁ, এটি ভুল অনুভব করে তবে মাঝে মধ্যে এটি ব্যবহারিক হয়। প্রাথমিক উদ্দেশ্য হ'ল ব্যবসায়ের প্রসঙ্গে কাজ করে এমন একটি API নকশা করা। যদি ব্যবসায়ের জন্য পুরোপুরি রেস্টলফুল যোগাযোগটি উপযুক্ত হয়, তবে এটির জন্য যান। যদি এটি না হয়, তবে এটির জন্য যাবেন না। তা হল, এমন একটি এপিআই ডিজাইন করুন যা আপনার নির্দিষ্ট ব্যবসায়ের প্রয়োজনীয়তা পূরণ করে। এটিকে RESTfull করার চেষ্টা করে ঘুরে বেড়ানোর কারণ এটির প্রাথমিক প্রয়োজনীয়তা "আমি এক্স / ওয়াই অ্যাডাপ্টারের প্যাটার্নটি কীভাবে ব্যবহার করব?" জিজ্ঞাসা করা থেকে আলাদা নয়। হর্ণের দৃষ্টান্তগুলিকে জুতো ব্যবহার করবেন না যতক্ষণ না তারা প্রকৃত, মূল্যবান সমস্যা সমাধান করে।

— luis.espinal

1

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

— এরিক এলিয়ট

2

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

GET api/users?filter=param1%3Dvalue1%26param2%3Dvalue2

আমি জানি এটি কুৎসিত তবে আমি মনে করি এটি করা সবচেয়ে আরামদায়ক উপায় এবং এটি সার্ভারে পার্স করা সহজ হওয়া উচিত :)

— Shanks
সূত্র