REST এপিআইয়ের জন্য নামকরণের কোনও গাইডলাইন রয়েছে? [বন্ধ]

212

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

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

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

এই প্রশ্নটি উন্নত করুন

REST এপিআইগুলি তৈরি করার সময়, এপিআই-র মধ্যে নামকরণের কনফারেন্সগুলির জন্য কোনও গাইডলাইন বা ডিফাক্টোর মান রয়েছে (যেমন: ইউআরএল এন্ডপয়েন্ট পথের উপাদানগুলি, ক্যোরিস্ট্রিং প্যারামিটার)? উটের ক্যাপগুলি কি আদর্শ, বা আন্ডারস্কোর হয়? অন্যান্য?

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

api.service.com/helloWorld/userId/x

অথবা

api.service.com/hello_world/user_id/x

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

যে কোনও গাইডলাইন প্রশংসা করা হবে।

api rest naming-conventions

— jnorris
সূত্র

150

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

সুতরাং আপনার ইউআরএলটি দেখতে এমন হওয়া উচিত (আপনি যেমন অনুরোধ করেছেন তেমন ডিজাইনের সমস্যাগুলি উপেক্ষা করে :-))

api.service.com/hello-world/user-id/x

— LiorH
সূত্র

187

আরএফসি 2616 অনুসারে শুধুমাত্র ইউআরএল এর স্কিম এবং হোস্ট অংশগুলি সংবেদনশীল নয়। বাকি ইউআরএল, অর্থাৎ পথ এবং ক্যোয়ারীটি কেস সংবেদনশীল হতে হবে। w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.2.3

— ড্যারেল মিলার

10

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

— ফেরায়

18

@ লিয়ারএইচ: আপনি কেন বিষয়টি সংবেদনশীল হিসাবে "বোধশক্তি" মনে করেন? অন্যান্য প্রসঙ্গের প্রচুর পরিমাণে ভাল প্রভাবের ক্ষেত্রে সংবেদনশীল। কিছু ওয়েব সার্ভিস (যেমন আমাজন এস 3) যে হয় না URL টি এন্ড পয়েন্ট কেনার ক্ষেত্রে দেখা সংবেদনশীলতা জোরদার, এবং আমি মনে করি এটা বেশ উপযুক্ত নয়।

— হাঙ্ক

6

@ ডেনিস উইন্ডোজ সার্ভার ফাইল সিস্টেমগুলি ডিফল্টরূপে সংবেদনশীল, যদি না আমি খুব খারাপভাবে

— প্রযুক্তিগত.মাইক্রোসফট

5

@ স্যামস্পট ভাল! আমি ভেবেছিলাম যে সার্ভারগুলি তৈরি করার সময় উইন্ডোজগুলি সংবেদনশীল ফাইলের নামগুলিতে সরাসরি চলে যায়। বাহ, তারা যতক্ষণ পারত ততক্ষণ তাদের পথ চালিয়ে যাচ্ছিল, যেমন "1 মাইক্রোসফ্ট ওয়ে"। ;-)

— ডেনিস

87

ড্রপবক্স , টুইটার , গুগল ওয়েব পরিষেবাদি এবং ফেসবুকের জন্য REST এপিআই সমস্ত আন্ডারস্কোর ব্যবহার করে।

— jz1108
সূত্র

24

এর একটি পার্শ্ব প্রতিক্রিয়া হ'ল গুগলের অনুসন্ধান সূচীতে একসাথে আন্ডারকর্ড করা 'শব্দ' সম্পূর্ণ রাখা হয়। হাইহেনটেডগুলি পৃথক কথায় বিভক্ত।

— ডেনিস

উদাহরণ: dev.twitter.com/docs/api/1.1

— মাইক কোজেলস্কি

11

গুগল ম্যাপস এপিআই যখন আন্ডারস্কোর ব্যবহার করে তবে গুগল স্টাইল গাইডের জন্য উটের কেস প্রয়োজন। Google+ এ এপিআই এবং কাস্টম অনুসন্ধান এপিআই অন্যান্যের মধ্যে উট কেস ব্যবহার করুন।

— বেনিয়ামিন

2

পি: বিভাজক হিসেবে সেই URL গুলিকে - তবুও তারা এখনও ব্যবহার '' developers.google.com/custom-search/json-api/v1/reference/cse/... developers.google.com/+/best-practices dev.twitter। com / ওভারভিউ / কেস-স্টাডি অন্যদিকে তারা ক্যোয়ারী প্যারামিটারগুলিতে উটকেস ব্যবহার করে।

— ম্যাটিয়াস

1

কেউ জানে না ...

— পাইটার কুলা

84

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

HelloWorldসম্পদ সত্যিই ভাল বর্গ নয়। এটি কোনও "জিনিস" বলে মনে হয় না। এটি হতে পারে, তবে এটি খুব বিশেষত্বের মতো নয়। ক greetingএকটি জিনিস।

user-idআপনি যে বিশেষ্যটি আনছেন তা হতে পারে। তবে সন্দেহজনক যে আপনার অনুরোধের ফলাফলটি কেবলমাত্র একটি ইউজার_ইড। অনুরোধের ফলাফলটি একজন ব্যবহারকারী হওয়ার সম্ভাবনা অনেক বেশি। সুতরাং, userআপনি যে বিশেষ্যটি আনছেন তা কি?

www.example.com/greeting/user/x/

আমার কাছে যৌক্তিক. আপনার REST অনুরোধকে এক প্রকার বিশেষ্য বাক্য তৈরি করার দিকে মনোনিবেশ করুন - শ্রেণিবিন্যাসের মাধ্যমে একটি পথ (বা শ্রেণিবদ্ধ, বা ডিরেক্টরি)। সম্ভব হলে বিশেষ্য বিশেষ্য ব্যবহার করুন, যদি সম্ভব হয় তবে বিশেষ্য বাক্যাংশগুলি এড়িয়ে চলুন।

সাধারণত, যৌগিক বিশেষ্য বাক্যাংশগুলির অর্থ সাধারণত আপনার শ্রেণিবিন্যাসের আরও একটি পদক্ষেপ। সুতরাং আপনার নেই /hello-world/user/এবং /hello-universe/user/। আপনার আছে /hello/world/user/এবং hello/universe/user/। বা সম্ভবত /world/hello/user/এবং /universe/hello/user/।

বিষয়টি হ'ল সংস্থানগুলির মধ্যে একটি নেভিগেশন পথ সরবরাহ করা।

— S.Lott
সূত্র

4

আমার প্রশ্নটি চূড়ান্ত প্যাথনামগুলির নামকরণ কনভেনশন এবং / অথবা ক্যোরিস্ট্রিং পরামিতিগুলি যাই হোক না কেন সে সম্পর্কিত concerning আমি আপনার সাথে নকশার সুপারিশগুলির সাথে একমত, তাই আপনাকে ধন্যবাদ, তবে এই প্রশ্নের সাথে আমি কেবল নামকরণের সম্মেলনগুলি সম্পর্কে জিজ্ঞাসা করছি।

— jnorris

1

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

— এহেলকে

30

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

একটি সংগ্রহ জিনিস
একটি জিনিস

একটি ভাল নামকরণ কনভেনশন হ'ল:

[POST or Create](To the *collection*)
sub.domain.tld/class_name.{media_type} 

[GET or Read](of *one* thing)
sub.domain.tld/class_name/id_value.{media_type}

[PUT or Update](of *one* thing)
sub.domain.tld/class_name/id_value.{media_type}

[DELETE](of *one* thing)
sub.domain.tld/class_name/id_value.{media_type}

[GET or Search](of a *collection*, FRIENDLY URL)
sub.domain.tld/class_name.{media_type}/{var}/{value}/{more-var-value-pairs}

[GET or Search](of a *collection*, Normal URL)
sub.domain.tld/class_name.{media_type}?var=value&more-var-value-pairs

যেখানে {মিডিয়া_ টাইপ এর মধ্যে একটি: জসন, এক্সএমএল, আরএসএস, পিডিএফ, পিএনজি, এমনকি এইচটিএমএল।

শেষে একটি 'গুলি' যুক্ত করে সংগ্রহটি আলাদা করা সম্ভব, যেমন:

'users.json' *collection of things*
'user/id_value.json' *single thing*

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

— ডেনিস
সূত্র

{Var with দিয়ে কী বোঝানো হয়েছে? যদি আমি নামের দ্বারা এমন কোনও ব্যবহারকারীর সন্ধান করি যা উদাহরণস্বরূপ ... / ব্যবহারকারী / ব্যবহারকারীর নাম / টমসওয়ার?

— হ্যান্স-পিটার স্টার

1

যদি আপনার তিনটি ভেরিয়েবল (var) এর নাম দেওয়া হয়েছে x, y, z, তবে আপনার URL টি দেখতে হবে: sub.domain.tld / x / value_of_x / y / value_of_y / z / value_of_z

— ডেনিস

@hstoerr আমি নিশ্চিত ছিলাম যে, বেশিরভাগ স্ক্রিপ্টের ভাষা কিছু ধরণের 'কোঁকড়া বন্ধনী পরিবর্তনশীল বিকল্প' ব্যবহার করে itution সুতরাং {var} বোঝায় যে কিছু পরিবর্তনশীল (এটির নাম) সেখানে বাস করে এবং তাই নিম্নলিখিত {মান} যেখানে তার আগে {var of এর মান। উদাহরণ: sub.domain.tld / স্ক্রিপ্ট / {var} / {মান} .জসন [www.yelp.com/food_reviews/review_averages_higher_than/4.json] খাবার রিভিউগুলি দেখানোর জন্য yelp.com থেকে জাসন ফলাফল পাওয়ার চেষ্টা করবে 4 এর চেয়ে বেশি মানের

— ডেনিস

এটি আমার মতে সেরা উত্তর এবং আন্তর্জাতিকভাবে চিন্তা করার জন্য কুডোস।

— বিলার

14

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

আরও তথ্যের জন্য, http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven দেখুন

— aehlke
সূত্র

44

এটিকে বিশ্রাম দিন ... সুন্দর ইউআরএল থাকা ভাল লাগল।

— এইচডিভ

1

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

— মাহেমফ

4

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

— এহেলকে

5

সংক্ষেপে, দুর্দান্ত দেখাচ্ছে URL গুলি দুর্দান্ত এবং প্রত্যেকের কাছে থাকা উচিত should যদিও এটি আরইএসটি-র সাথে কিছুই করার নেই।

— এহেলকে

1

এটি পরিষ্কার করার জন্য @ এহেলকে ধন্যবাদ বিশ্রাম ইউআরএল স্ট্রাকচার সম্পর্কে নয়। লোকেরা বুঝতে এত কষ্ট কেন আমি বুঝতে পারছি না।

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

9

ডোমেন নামগুলি সংবেদনশীল নয় তবে বাকি ইউআরআই অবশ্যই হতে পারে। ইউআরআইগুলি কেস সংবেদনশীল নয় বলে ধরে নেওয়া বড় ভুল।

6

আমার কাছে http://soaprobe.blogspot.co.uk/2012/10/soa-rest-service-naming-guidline.html এ গাইডলাইনের একটি তালিকা রয়েছে যা আমরা প্রোডে ব্যবহার করেছি। গাইডলাইনগুলি সর্বদা বিতর্কযোগ্য ... আমি মনে করি জিনিসগুলি নিখুঁত হওয়ার চেয়ে কখনও কখনও ধারাবাহিকতা গুরুত্বপূর্ণ হয় (যদি এমন কোনও জিনিস থাকে)।

— রবার্ট মোর্শেল
সূত্র

2

আমি মনে করি না যে উটের মামলাটি সেই উদাহরণটিতে সমস্যা, তবে আমি কল্পনা করি যে উপরের উদাহরণের জন্য আরও একটি বিশ্রামের নামকরণ কনভেনশন হ'ল:

api.service.com/helloWorld/userId/x

তারপরে ব্যবহারকারীকে কোয়েরি প্যারামিটার তৈরি করা (যা পুরোপুরি আইনী) আমার উদাহরণটি সেই সংস্থানটিকে আইএমও, আরও বিশ্রামের উপায়ে বোঝায়।

— Gandalf
সূত্র

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

— জনিরিস

ওয়েল যেহেতু REST এ আপনার ইউআরএলগুলি হ'ল আপনার ইন্টারফেস তাই এটি কোনও এপিআই প্রশ্নের মতো। যদিও আমি মনে করি না যে আপনার উদাহরণের সাথে নির্দিষ্ট কোনও নির্দেশিকা রয়েছে, তবে আমি ব্যক্তিগতভাবে উটের মামলায় যাব with

— গ্যান্ডাল্ফ

আপনি HTTP স্ট্যাকের যে কোনও স্তরে ক্যাশে হতে চান এমন সংস্থানগুলির জন্য কোয়েরি পরামিতিগুলি ব্যবহার করা উচিত নয়।

— এহেল্কে

@aehlke ঠিক বিপরীতটি সত্যকে ধরেছে। আপনি যদি ক্যোয়ারী প্যারামিটারগুলি ক্যাশে করতে চান না, তবে প্যারামিটারগুলির জন্য GET স্টাইলটি ব্যবহার করুন, c বা anything আপনি যে সমস্ত কিছু ক্যাশে চান না তার জন্য অ্যান্টি ক্যাচিং শিরোনাম সংশোধন / সন্নিবেশ করতে DARN SURE তৈরি করুন। এছাড়াও, থ্রেস হ'ল কিছু শিরোনাম যা অবজেক্ট / পৃষ্ঠার returend এর একটি হ্যাশ, আপনি যে জিনিসগুলি ক্যাশে চান সেগুলি পরিবর্তন করতে ইঙ্গিত করতে এটি ব্যবহার করুন, তবে সম্পাদনাগুলি থাকলে আপডেট হবে।

— ডেনিস

@এহল্কে ক্যাচিং সম্পর্কে জানতে পেরে এটি যুক্ত করছি। আমি একটি কোডক্যাম্পের উপস্থাপনাটি স্মরণ করি যেখানে স্পিডআপগুলির মধ্যে একটি এই সমস্ত শিরোলেখ সম্পাদন করছিল, এবং তারপরে ফাইলের নাম এবং সমস্ত রেফারেন্সগুলি পরিবর্তন করা যখন বর্উসার এবং প্রক্সিগুলিকে সার্ভারে নতুন সংস্করণে পাওয়ার জন্য একটি নতুন ক্যাশে সময় চলছিল সেট। এখানে সমস্ত অদ্ভুত বিবরণ রয়েছে: developers.google.com/speed/docs/best-practices/caching

— ডেনিস

2

যদি আপনি Oauth2 দিয়ে আপনার ক্লায়েন্টদের অনুমোদন করেন তবে আমি মনে করি আপনার কমপক্ষে দুটি প্যারামিটার নামের জন্য আপনার আন্ডারস্কোর প্রয়োজন হবে:

client_id
client_secret

আমি আমার (এখনও প্রকাশিত হয়নি) আরএসটি এপিআইতে উট কেস ব্যবহার করেছি। এপিআই ডকুমেন্টেশন লেখার সময় আমি স্নাপকেসে সমস্ত পরিবর্তন করার কথা ভাবছিলাম তাই অন্য প্যারামগুলি না থাকায় Oauth প্যারামগুলি কেন স্নাপকেস হয় তা আমাকে ব্যাখ্যা করতে হবে না।

দেখুন: https://tools.ietf.org/html/rfc6749

— মাইকেল
সূত্র

0

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

এছাড়াও, আমি মনে করি গ্যান্ডাল্ফটি সঠিক, কোয়েরি স্ট্রিং প্যারামিটারগুলি ব্যবহার না করা সাধারণত REST এ পরিষ্কার থাকে তবে পরিবর্তে আপনি কোন সংস্থানগুলি মোকাবেলা করতে চান তা নির্ধারণ করে এমন পথ তৈরি করে।

http://api.example.com/HelloWorld/Users/12345/Order/3/etc

— অ্যান্ডি হোয়াইট
সূত্র