অনুসন্ধানের জন্য বিশদ URL টি ডিজাইন


427

আমি বিশ্রামের ইউআরএল হিসাবে অনুসন্ধানগুলি উপস্থাপনের জন্য যুক্তিসঙ্গত উপায় খুঁজছি।

সেটআপ: আমার কাছে দুটি মডেল রয়েছে গাড়ি এবং গ্যারেজ, যেখানে গাড়িগুলি গ্যারেজে থাকতে পারে। সুতরাং আমার ইউআরএলগুলি দেখতে দেখতে:

/car/xxxx
  xxx == car id
  returns car with given id

/garage/yyy
  yyy = garage id
  returns garage with given id

একটি গাড়ি নিজে থেকেই বিদ্যমান থাকতে পারে (সুতরাং / গাড়ী), বা এটি একটি গ্যারেজে উপস্থিত থাকতে পারে। প্রদত্ত গ্যারেজে সমস্ত গাড়ি উপস্থাপন করার সঠিক উপায় কী? কিছুটা এইরকম:

/garage/yyy/cars     ?

গ্যারেজ ইয়ে এবং জেডজেটে গাড়িগুলির মিলন সম্পর্কে কীভাবে?

নির্দিষ্ট বৈশিষ্ট্যযুক্ত গাড়িগুলির জন্য অনুসন্ধানের প্রতিনিধিত্ব করার সঠিক উপায় কী? বলুন: আমাকে 4 টি দরজা সহ সমস্ত নীল রঙের সেল্ডান দেখান:

/car/search?color=blue&type=sedan&doors=4

অথবা এটি পরিবর্তে / গাড়ি থাকা উচিত?

"অনুসন্ধান" এর ব্যবহারটি সেখানে অনুপযুক্ত বলে মনে হচ্ছে - এর চেয়ে ভাল উপায় / শব্দটি কী? এটা ঠিক হওয়া উচিত:

/cars/?color=blue&type=sedan&doors=4

অনুসন্ধানের পরামিতিগুলি কি পাঠ্যফো বা QUERYSTRING এর অংশ হওয়া উচিত?

সংক্ষেপে, আমি ক্রস-মডেল REST ইউআরএল ডিজাইন, এবং অনুসন্ধানের জন্য গাইডেন্স খুঁজছি।

[আপডেট] আমি জাস্টিনের উত্তরটি পছন্দ করি তবে তিনি মাল্টি-ফিল্ড অনুসন্ধানের বিষয়টি কভার করেন না:

/cars/color:blue/type:sedan/doors:4

বা এই জাতীয় কিছু। আমরা কীভাবে যেতে পারি

/cars/color/blue

একাধিক ফিল্ড কেস?


16
যদিও এটি ইংরেজিতে ভাল দেখায়, মিক্সিং /carsএবং /carsemantical এবং সেইজন্য একটি খারাপ ধারণা নয়। যখন বিভাগের অধীনে একাধিক আইটেম থাকে তখন সর্বদা বহুবচন ব্যবহার করুন।
জাজ

4
এগুলি খারাপ উত্তর। অনুসন্ধানে কোয়েরি স্ট্রিং ব্যবহার করা উচিত। সঠিকভাবে ব্যবহৃত হওয়ার সময় অনুসন্ধানের স্ট্রিংগুলি 100% রিস্টাল হয় (যেমন, অনুসন্ধানের জন্য)।
pbreitenbach

উত্তর:


435

অনুসন্ধানের জন্য, ক্যোরিস্ট্রিংগুলি ব্যবহার করুন। এটি পুরোপুরি বিশ্রামযুক্ত:

/cars?color=blue&type=sedan&doors=4

নিয়মিত ক্যোরিস্ট্রিংয়ের একটি সুবিধা হ'ল এগুলি মানক এবং ব্যাপকভাবে বোঝা যায় এবং সেগুলি ফর্ম-গিট থেকে উত্পন্ন করা যায়।


42
এটা সঠিক। ক্যোয়ারী স্ট্রিংগুলির পুরো পয়েন্টটি অনুসন্ধানের মতো কাজ করার জন্য।
এহেলকে

22
প্রকৃতপক্ষে এটি RFC3986 অনুসারে সঠিক এবং পথ এবং ক্যোয়ারিং স্ট্রিংটি সংস্থানটিকে চিহ্নিত করে। আরও কি, সঠিক নামকরণ সহজভাবে হবে /cars?color=whatever
লোয়েকি

35
আপনি যে তুলনামূলক (>, <, <=,> =) চান সেখানে কী হবে? / কার? রেটিং <= 3?
জেসি

3
আপনি যদি ক্যোয়ারী স্ট্রিংয়ের নীচে নেস্টেড রিসোর্সগুলি অ্যাক্সেস করতে চান? উদাহরণস্বরূপ /cars?color=blue&type=sedan&doors=4/enginesকাজ করবে না
অ্যাবে ভোলেকার

9
@ এমজেএস গাড়ি তালিকায় /cars?param=valueসহজ ফিল্টারিংয়ের জন্য এবং /cars/search?param=valueএকটি অনুসন্ধান তৈরি করার জন্য ( অবিচ্ছিন্নভাবে ওউ সহ) যেখানে ফলাফলের মধ্যে অনুসন্ধানের স্কোরিং, শ্রেণিবদ্ধকরণ ইত্যাদি থাকতে পারে আপনি কোনও নামযুক্ত অনুসন্ধানও তৈরি / মুছতে পারবেন /cars/search/mysearch। এটি দেখুন: স্ট্যাকওভারফ্লো.com
ইয়ভেস এম।

121

RESTful চমত্কার URL টি নকশা একটি কাঠামো উপর ভিত্তি করে একটি সম্পদ প্রদর্শন করার সম্পর্কে (ডিরেক্টরি মত গঠন, তারিখ: প্রবন্ধ / 2005/5/13, বস্তু এবং এটা গুণাবলী, ..), স্ল্যাশ /হায়ারারকিকাল গঠন নির্দেশ করে, ব্যবহার -idপরিবর্তে।

শ্রেণিবদ্ধ কাঠামো

আমি ব্যক্তিগতভাবে পছন্দ করব:

/garage-id/cars/car-id
/cars/car-id   #for cars not in garages

যদি কোনও ব্যবহারকারী /car-idঅংশটি সরিয়ে দেয় তবে তা carsপূর্বরূপ এনেছে - স্বজ্ঞাত। ব্যবহারকারী ঠিক জানেন যে তিনি গাছটিতে কোথায় আছেন, তিনি কী দেখছেন। তিনি প্রথম চেহারা থেকে জানেন যে গ্যারেজ এবং গাড়ি সম্পর্কযুক্ত। /car-idএছাড়াও উল্লেখ করে এটি অসদৃশ একসঙ্গে জন্যে /car/id

অনুসন্ধানের

অনুসন্ধান অনুসন্ধান যেমন আছে ঠিক আছে, কেবলমাত্র আপনার পছন্দ আছে, কী বিবেচনায় নেওয়া উচিত। মজাদার অংশটি অনুসন্ধানগুলিতে যোগদান করার সময় আসে (নীচে দেখুন)।

/cars?color=blue;type=sedan   #most prefered by me
/cars;color-blue+doors-4+type-sedan   #looks good when using car-id
/cars?color=blue&doors=4&type=sedan   #I don't recommend using &*

বা মূলত যা কিছু উপরে বর্ণিত হিসাবে স্ল্যাশ নয়।
সূত্র:, /cars[?;]color[=-:]blue[,;+&]* যদিও আমি &সাইনটি প্রথম নজরে পাঠ্য থেকে অজানা হিসাবে এটি ব্যবহার করব না ।

** আপনি কি জানেন যে ইউআরআইতে জেএসওএন অবজেক্টটি পাস করা বিশ্রামযোগ্য? **

বিকল্পের তালিকা

/cars?color=black,blue,red;doors=3,5;type=sedan   #most prefered by me
/cars?color:black:blue:red;doors:3:5;type:sedan
/cars?color(black,blue,red);doors(3,5);type(sedan)   #does not look bad at all
/cars?color:(black,blue,red);doors:(3,5);type:sedan   #little difference

সম্ভাব্য বৈশিষ্ট্য?

নেগেট অনুসন্ধানের স্ট্রিং (!)
কোনও গাড়ি অনুসন্ধান করতে, তবে কালো নয় এবং লাল :
?color=!black,!red
color:(!black,!red)

যোগ দিয়েছে অনুসন্ধানসমূহ
অনুসন্ধান লাল বা নীল বা কালো সাথে গাড়ি 3 গ্যারাজের আইডি দরজা 1..20 বা 101..103 বা 999 কিন্তু না 5 টি /garage[id=1-20,101-103,999,!5]/cars[color=red,blue,black;doors=3]
আপনি আরও জটিল অনুসন্ধান অনুসন্ধান তৈরি করতে পারেন( সাবস্ট্রিংগুলির সাথে মিলের ধারণার জন্য CSS3 অ্যাট্রিবিউটের মিলটি দেখুন Eg যেমন "বার" যুক্ত ব্যবহারকারীদের সন্ধান করুন user*=bar))

উপসংহার

যাইহোক, এটি আপনার পক্ষে সবচেয়ে গুরুত্বপূর্ণ অংশ হতে পারে, কারণ আপনি এটি সর্বোপরি পছন্দ করতে পারেন তবে কেবল মনে রাখবেন RESTful কোনো URI একটি কাঠামো যা সহজে বোঝা যেমন ডিরেক্টরি-মত হল প্রতিনিধিত্ব করে /directory/file, /collection/node/item, তারিখ /articles/{year}/{month}/{day}.. আর আপনি যখন বর্জন শেষ বিভাগগুলির মধ্যে যে কোনও, আপনি কী পান তা তাত্ক্ষণিকভাবে জানবেন।

সুতরাং .., এই সমস্ত চরিত্র বিনা কোডবিহীন অনুমতি দেওয়া হয়েছে :

  • অসংরক্ষিত: a-zA-Z0-9_.-~
    সাধারণত এনকোডযুক্ত এবং না উভয়ই অনুমোদিত, উভয় ব্যবহারের পরে সমতুল্য।
  • বিশেষ অক্ষর: $-_.+!*'(),
  • সংরক্ষিত: ;/?:@=&
    যে কারণে তারা প্রতিনিধিত্ব করে তার জন্য বিনা কোডে ব্যবহার করা যেতে পারে, অন্যথায় তাদের অবশ্যই এনকোড করা উচিত।
  • অনিরাপদ: <>"#%{}|\^~[]`
    কেন অনিরাপদ এবং কেন পরিবর্তে এনকোড করা উচিত: আরএফসি 1738 দেখুন ২.২

    আরো দেখুন বোঝায় যা RFC 1738 # পৃষ্ঠা-20 আরো চরিত্র শ্রেণীর জন্য।

আরএফসি 3986 দেখুন 2.2
সত্ত্বেও আমি যা বলেছিলাম তা সত্ত্বেও এখানে বিস্ময়করদের একটি সাধারণ পার্থক্য রয়েছে যার অর্থ কিছু " অন্যের চেয়ে বেশি গুরুত্বপূর্ণ।

  • জেনেরিক সীমানা: :/?#[]@
  • উপ-delimeters: !$&'()*+,;=

আরও পঠন:
শ্রেণিবিন্যাস: ২.৩ দেখুন , দেখুন 1.2.3
url পাথ প্যারামিটার সিনট্যাক্স
CSS3 বৈশিষ্ট্য মেলে
আইবিএম: RESTful ওয়েব পরিষেবাদি - মূল বিষয়গুলি
দ্রষ্টব্য: আরএফসি 1738 আরএফসি 3986 দ্বারা আপডেট হয়েছিল


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

4
@ কিওয়ার্টি: দুর্দান্ত পোস্ট! আমি ভাবছিলাম: কেবলমাত্র পাঠযোগ্যতার ;বিরোধিতা হিসাবে ব্যবহার করার একমাত্র কারণ &? কারণ যদি তাই হয়, তবে আমি মনে করি যে আমি প্রকৃতপক্ষে পছন্দ করবো &কারণ এটি আরও সাধারণ ডেলিমিটার ... তাই না? :) ধন্যবাদ!
ফ্লো

3
@ ফ্লো হ্যাঁ ঠিক :), তবে মনে রাখবেন যে &একটি ডিলিমিটার হিসাবে কেবল বিকাশকারীদেরই পরিচিত। পিতা-মাতা, দাদা-দাদি এবং অ-শিক্ষিত জনগোষ্ঠী প্রচলিত লিখিত পাঠ্যে ব্যবহৃত হিসাবে সীমানা গ্রহণকারীদের গ্রহণ করে।
কিওয়ার্টি

17
যখন ক্যোয়ারী স্ট্রিংগুলি ভালভাবে বোঝা যায় এবং মানক হয় তখন কেন একটি নন-স্ট্যান্ডার্ড স্কিম তৈরি করা হয়?
pbreitenbach

1
@ কিউয়ারটি আপনাকে অনুসন্ধান / অনুসন্ধান থেকে থামছে না? গাড়ি = লাল, নীল, সবুজ এবং গ্যারেজ = 1,2,3 বা আপনি যদি একটি <মাল্টিলেক্ট> ফর্ম ব্যবহার করেন: / অনুসন্ধান? গাড়ি = লাল এবং গাড়ি = নীল এবং গ্যারেজ = 1 এবং গ্যারেজ = 2
pbreitenbach

36

যদিও পথটিতে প্যারামিটার থাকার কিছু সুবিধা রয়েছে, আইএমও রয়েছে, কিছু বহির্মুখী কারণ রয়েছে।

  • অনুসন্ধানের ক্যোয়ারির জন্য প্রয়োজনীয় সমস্ত অক্ষরের URL টি অনুমোদিত নয়। বেশিরভাগ বিরামচিহ্ন এবং ইউনিকোড অক্ষরগুলির জন্য কোয়েরি স্ট্রিং প্যারামিটার হিসাবে URL এনকোড হওয়া দরকার। আমি একই সমস্যা নিয়ে কুস্তি করছি। আমি ইউআরএল-এ এক্সপথ ব্যবহার করতে চাই, তবে সমস্ত এক্সপথ সিনট্যাক্স ইউআরআই পাথের সাথে সামঞ্জস্য নয়। সুতরাং সরল পথগুলির জন্য, ড্রাইভারের দরজা এক্সএমএল নথিতে /cars/doors/driver/lock/combination' combination' উপাদানটি সনাক্ত করা যথাযথ হবে । তবে /car/doors[id='driver' and lock/combination='1234']তেমন বন্ধুত্বপূর্ণ নয়।

  • রিসোর্সের একটি বৈশিষ্ট্যের উপর ভিত্তি করে রিসোর্স ফিল্টারিং এবং সংস্থান নির্দিষ্ট করার মধ্যে পার্থক্য রয়েছে।

    উদাহরণস্বরূপ, যেহেতু

    /cars/colors সমস্ত গাড়ির জন্য সমস্ত রঙের একটি তালিকা ফেরত দেয় (ফেরত দেওয়া সংস্থানটি রঙের সামগ্রীর সংগ্রহ)

    /cars/colors/red,blue,green রঙের অবজেক্টের একটি তালিকা ফেরত দেবে যা লাল, নীল বা সবুজ রঙের, গাড়ির সংকলন নয়।

    গাড়ি ফেরাতে, পথ হবে

    /cars?color=red,blue,green অথবা /cars/search?color=red,blue,green

  • পথের পরামিতিগুলি পড়া আরও বেশি কঠিন কারণ নাম / মান জোড়াটি বাকি পথ থেকে আলাদা করা হয় না, যা নাম / মান জোড়া নয়।

একটি শেষ মন্তব্য। আমি /garages/yyy/cars(সর্বদা বহুবচন) পছন্দ করি/garage/yyy/cars (সম্ভবত এটি মূল উত্তরের একটি টাইপ ছিল) কারণ এটি একবচন এবং বহুবচনগুলির মধ্যে পথ পরিবর্তন করা এড়িয়ে যায়। একটি যোগ 's' এর সাথে শব্দের জন্য, পরিবর্তন এত খারাপ নয়, কিন্তু পরিবর্তন /person/yyy/friendsকরতে /people/yyyকষ্টকর মনে হয়।


2
হ্যাঁ, আমি একমত ... এছাড়াও আমি url এর দিকের কাঠামোর সত্তার মধ্যে প্রাকৃতিক সম্পর্ককে প্রতিবিম্বিত করা উচিত, আমার সংস্থানগুলির মানচিত্রের কোনও ধরণের, যেমন একটি গ্যারেজে অনেক গাড়ি রয়েছে, একটি গাড়ি একটি গ্যারেজের অন্তর্গত ... এবং আসুন ফিল্টার প্যারামিটার, কারণ আমরা কি কথা বলছি ক্যোরিস্ট্রিং ক্যু ... আপনি কি মনে করেন?

31

পিটারের উত্তরে প্রসারিত করতে - আপনি অনুসন্ধানকে প্রথম-শ্রেণীর সংস্থান করতে পারেন:

POST    /searches          # create a new search
GET     /searches          # list all searches (admin)
GET     /searches/{id}     # show the results of a previously-run search
DELETE  /searches/{id}     # delete a search (admin)

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

অনুসন্ধানগুলি ব্যবহার করার জন্য অনেকগুলি সম্ভাবনা রয়েছে যখন আপনি এগুলিকে সংস্থান হিসাবে মনে করেন।

এই রেলকাস্টে ধারণাটি আরও বিশদে ব্যাখ্যা করা হয়েছে ।


6
এই পদ্ধতির অস্থির প্রোটোকল নিয়ে কাজ করার ধারণার বিরুদ্ধে যায় না? মানে, ডিবিতে অনুসন্ধান চালিয়ে যাওয়া রাষ্ট্রীয় সংযোগ স্থাপনের অর্থ ... তাই না?

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

2
উপরেরগুলি কীভাবে একটি ইউআরআই কনভেনশনকে সংজ্ঞায়িত করে?
ধনী আপোডাচ

3
REST এর সুন্দর ইউআরআই বা ইউআরআই নেস্টিং ইত্যাদির সাথে কিছুই করার নেই যদি আপনি আপনার API এর অংশ হিসাবে ইউআরআই সংজ্ঞায়িত করেন তবে এটি বিশ্রাম নয়।
এহেল্কে

2
আমি এর আগেও যুক্তি দিয়েছি। এটি কোনওভাবেই রাষ্ট্রীয় নয়, তবে এটি একটি ভয়াবহ বিষয়। অনুসন্ধানের 'মুছুন' পুরোপুরি পরিষ্কার নয়, এখানে আপনি বলছেন এটি এটি এই অনুসন্ধান সত্তাটিকে মুছে ফেলেছে, তবে আমি এটি ব্যবহার করতে চাই এটি অনুসন্ধানের মাধ্যমে পাওয়া ফলাফলগুলি মুছে ফেলতে চাই। একটি উত্স হিসাবে 'অনুসন্ধান' যোগ করবেন না দয়া করে।
thecoshman

12

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

/search/{searchQuery}

অথবা

/search/{savedSearchName}

11
কোন। এটি কখনই কোনও ক্রিয়া একটি সংস্থান হিসাবে বোধ করা উচিত।
thecoshman

3
উপরের মন্তব্যে যেমনটি বলা হয়েছে @ থিকোশম্যান, অনুসন্ধানও একটি বিশেষ্য।
andho

6

আমি অনুসন্ধানগুলি প্রয়োগ করতে দুটি পন্থা ব্যবহার করি।

1) সম্পর্কিত উপাদানগুলির অনুসন্ধানের জন্য, এবং নেভিগেশনের জন্য সহজতম কেস।

    /cars?q.garage.id.eq=1

এর অর্থ, গ্যারেজ আইডি থাকা 1 টির সমান গাড়িগুলি।

আরও জটিল অনুসন্ধানগুলি তৈরি করাও সম্ভব:

    /cars?q.garage.street.eq=FirstStreet&q.color.ne=red&offset=300&max=100

ফার্স্ট স্ট্রিটের সমস্ত গ্যারেজে থাকা গাড়িগুলি যা লাল নয় (তৃতীয় পৃষ্ঠা, প্রতি পৃষ্ঠায় 100 উপাদান)।

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

    POST /searches  => Create
    GET  /searches/1  => Recover search
    GET  /searches/1?offset=300&max=100  => pagination in search

অনুসন্ধান তৈরির জন্য পোস্টের বডিটি নিম্নরূপ:

    {  
       "$class":"test.Car",
       "$q":{
          "$eq" : { "color" : "red" },
          "garage" : {
             "$ne" : { "street" : "FirstStreet" }
          }
       }
    }

এটি গ্রেইলে ভিত্তিক (মানদণ্ড ডিএসএল): http://grails.org/doc/2.4.3/ref/Domain%2020 শ্রেণি / ক্রিয়েটক্রিটরিয়া html


5

এটি বিশ্রাম নয়। আপনি আপনার এপিআই-র অভ্যন্তরের জন্য ইউআরআই সংজ্ঞা দিতে পারবেন না। সংস্থান নেভিগেশন হাইপারটেক্সট চালিত হতে হবে। যদি আপনি বেশ ইউআরআই এবং ভারী পরিমাণে সংযুক্তি চান তবে এটি ঠিক আছে, তবে কেবল এটিকে REST বলবেন না, কারণ এটি সরাসরি রেস্টস্টুল আর্কিটেকচারের সীমাবদ্ধতা লঙ্ঘন করে।

REST এর আবিষ্কারক এই নিবন্ধটি দেখুন ।


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

2
আমি দুঃখিত, আপনি ঠিক বলেছেন। আমি কেবল ওপি থেকে এই ধারণাটি পেয়েছি যে তিনি কীভাবে ইউআরএলগুলি তৈরি করবেন সে সম্পর্কে ক্লায়েন্টদের সচেতন করতে যাচ্ছেন - তিনি ইউআরএলকে তার এপিআইয়ের "লেআউট" অংশ হিসাবে তৈরি করবেন। এটি রেস্টের লঙ্ঘন হবে।
এহেলকে

@ এহেল্কে, আপনার মন্তব্যের সাথে মিল রাখতে আপনার উত্তরটি আপডেট করা উচিত।
জেমস ম্যাকমাহন

1
এটি স্তরের 2 রিচার্ডসন পরিপক্কতার মডেল অনুগত। আপনি স্তর 3 এর কথা উল্লেখ করছেন Just কেবলমাত্র REST কে অগ্রগামীভাবে গ্রহণযোগ্য কিছু হিসাবে গ্রহণ করুন।
জুলস র্যান্ডলফ

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

1

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

আমি এটি যেভাবে দেখছি, আপনি নির্দিষ্ট সংস্থানগুলি যেভাবে পরিচালনা করছেন আপনি তাতে এটি তৈরি করতে পারেন:
/ গাড়ি / ক্যাম *

বা আপনি কেবল এটি ফিল্টারটিতে জুড়তে পারেন:
/ গাড়ি / দরজা / ৪ / নাম / ক্যাম * / রং / লাল, নীল, সবুজ

ব্যক্তিগতভাবে, আমি দ্বিতীয়টি পছন্দ করি তবে আমি কোনওভাবেই আরইএসটি-র বিশেষজ্ঞ নই (এটি প্রথম মাত্র 2 বা তাই সপ্তাহ আগে শুনেছি ...)


এটি পছন্দ করুন:/cars?name=cam*
ড্যানমান

1

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

RESTful API এর ডিজাইনের সর্বোত্তম অনুশীলনগুলি বুঝতে আপনি http://saipraveenblog.wordpress.com/2014/09/29/rest-api-best-practices/ এর মাধ্যমে যেতে পারেন


1
অনুসন্ধানও একটি বিশেষ্য
😀

1

তদতিরিক্ত আমি আরও পরামর্শ দেব:

/cars/search/all{?color,model,year}
/cars/search/by-parameters{?color,model,year}
/cars/search/by-vendor{?vendor}

এখানে, Searchশিশুদের সংস্থান হিসাবে বিবেচনা করা হয় Cars


1

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

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

এটি অনুসন্ধানের আরও নমনীয় বর্ণনার পাশাপাশি সার্ভার ইউআরএল দৈর্ঘ্য সীমা এড়িয়ে চলে।


-4

আমার পরামর্শটি হ'ল:

/garages
  Returns list of garages (think JSON array here)
/garages/yyy
  Returns specific garage
/garage/yyy/cars
  Returns list of cars in garage
/garages/cars
  Returns list of all cars in all garages (may not be practical of course)
/cars
  Returns list of all cars
/cars/xxx
  Returns specific car
/cars/colors
  Returns lists of all posible colors for cars
/cars/colors/red,blue,green
  Returns list of cars of the specific colors (yes commas are allowed :) )

সম্পাদনা:

/cars/colors/red,blue,green/doors/2
  Returns list of all red,blue, and green cars with 2 doors.
/cars/type/hatchback,coupe/colors/red,blue,green/
  Same idea as the above but a lil more intuitive.
/cars/colors/red,blue,green/doors/two-door,four-door
  All cars that are red, blue, green and have either two or four doors.

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

এখানে REST- এ ক্যোয়ারী স্ট্রিংয়ের কুফলগুলি বর্ণনা করে এমন একটি পৃষ্ঠার লিঙ্ক: http://web.archive.org/web/20070815111413/http://rest.blueoxen.net/cgi-bin/wiki.pl?QueryStringsConsideredHarmful

আমি গুগলের ক্যাশে ব্যবহার করেছি কারণ স্বাভাবিক পৃষ্ঠাটি এখানে আমার জন্য সেই লিঙ্কটিও কাজ করছে না: http://rest.blueoxen.net/cgi-bin/wiki.pl?QueryStringsConsideredHarmful


1
বিস্তারিত উত্তর দেওয়ার জন্য ধন্যবাদ। শেষটিতে, আমি যদি রঙ এবং দরজা উভয় দিয়ে অনুসন্ধান করতে চাই তবে কী হবে? / গাড়ি / রঙ / লাল, নীল, সবুজ / দরজা / 4 এটি সঠিক বলে মনে হচ্ছে না।
পরান্দ্র

2
ইউআরএল কমাগুলি আমার কাছে সঠিক মনে হয় না তবে এখনও বৈধ বিশ্রাম। আমি মনে করি এটি কেবল একটি দৃষ্টান্তের শিফট।
জাস্টিন বোজনিয়ার

21
আমি এই পরামর্শ পছন্দ করি না। আপনি মধ্যে পার্থক্য কিভাবে জানতে চাই /cars/colors/red,blue,greenএবং /cars/colors/green,blue,red? ইউআরআইয়ের পথের উপাদানটি স্তরবিন্যাসযুক্ত হওয়া উচিত, এবং আমি সত্যই এখানে দেখতে পাচ্ছি না। আমি মনে করি এটি এমন একটি পরিস্থিতি যেখানে ক্যোরি-স্ট্রিংটি সবচেয়ে উপযুক্ত পছন্দ।
ট্রয়লস্কন

62
এটি একটি খারাপ উত্তর। প্রকৃতপক্ষে অনুসন্ধানের প্রয়োগের সঠিক উপায়টি হল ক্যোয়ারী স্ট্রিং with সঠিকভাবে ব্যবহার করা হলে কোয়েরি স্ট্রিংগুলি সামান্যতম ক্ষেত্রেই মন্দ নয়। উদ্ধৃত নিবন্ধটি অনুসন্ধানের কথা উল্লেখ করছে না। প্রদত্ত উদাহরণগুলি পরিষ্কারভাবে নির্যাতন করা হয়েছে এবং আরও পরামিতিগুলির সাথে ভালভাবে ধরে রাখবে না।
pbreitenbach

4
ক্যোরিস্ট্রিংগুলি মূলত একাধিক পরামিতি সহ কোনও উত্স অনুসন্ধানের সমস্যা সমাধানের জন্য তৈরি করা হয়েছিল। একটি "রিস্টফুল" এপিআই সক্ষম করতে ইউআরআইকে রূপান্তর করা বিপজ্জনক এবং সংক্ষিপ্ত দৃষ্টিশক্তিযুক্ত বলে মনে হচ্ছে - বিশেষত যেহেতু আপনাকে কেবল ইউআরআইতে প্যারামিটারগুলির বিভিন্ন ক্রিয়াকলাপ পরিচালনা করতে নিজের জটিল ম্যাপিংগুলি লিখতে হবে। আরও ভাল, আপনার ইউআরআইগুলিতে
আনাতোলি জি
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.