REST বোঝা: ক্রিয়াগুলি, ত্রুটি কোডগুলি এবং প্রমাণীকরণ

602

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

আমি চারপাশে দেখেছি এবং বেশ কয়েকটি "কঙ্কাল" ফ্রেমওয়ার্ক পেয়েছি। আমার প্রশ্নের উত্তরগুলির পাশাপাশি, টনিক রয়েছে , একটি REST কাঠামো আমার পছন্দ কারণ এটি খুব লাইটওয়েট।

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

1. আমি কি ঠিক বুঝতে পারি?

বলুন আমার একটি সংস্থান আছে "ব্যবহারকারী"। আমি এরকম অনেকগুলি ইউআরআই সেট আপ করতে পারতাম:

/api/users     when called with GET, lists users
/api/users     when called with POST, creates user record
/api/users/1   when called with GET, shows user record
               when called with PUT, updates user record
               when called with DELETE, deletes user record

এটি কি এখনও পর্যন্ত কোনও রেস্টস্টুল আর্কিটেকচারের সঠিক উপস্থাপনা?

আমার আরও ক্রিয়াপদ দরকার

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

ব্যবহারকারীর উদাহরণে মনে আসা কিছু হ'ল:

activate_login
deactivate_login
change_password
add_credit

একটি বিশ্রামদায়ক URL আর্কিটেকচারের মতো কর্মগুলি আমি কীভাবে প্রকাশ করব?

আমার প্রবৃত্তিটি কোনও ইউআরএল-এর মতো জিইটি কল করা 

/api/users/1/activate_login

এবং একটি স্থিতি কোড ফিরে আশা।

যদিও এটি HTTP ক্রিয়া ব্যবহারের ধারণা থেকে বিচ্যুত হয়। আপনি কি মনে করেন?

৩. কীভাবে ত্রুটি বার্তা এবং কোডগুলি ফিরবেন

আরইএসটি-র সৌন্দর্যের একটি দুর্দান্ত অংশটি স্ট্যান্ডার্ড এইচটিটিপি পদ্ধতি ব্যবহার থেকে আসে। একটি ত্রুটিতে, আমি একটি 3xx, 4xx বা 5xx ত্রুটি স্থিতির কোড সহ একটি শিরোনাম নির্গত করি। বিস্তারিত ত্রুটির বর্ণনার জন্য, আমি শরীরটি (ডান?) ব্যবহার করতে পারি। এ পর্যন্ত সব ঠিকই. তবে কী কী ভুল হয়েছে (উদাহরণস্বরূপ "ডাটাবেসের সাথে সংযোগ করতে ব্যর্থ হয়েছে", বা "ডাটাবেস লগইন ভুল") এর মালিকানাধীন ত্রুটি কোড সংক্রমণ করার উপায় কী হবে ? আমি যদি বার্তাটির সাথে এটি শরীরে রাখি তবে আমার পরে এটি পার্স করতে হবে। এই জাতীয় জিনিস জন্য একটি মানক শিরোনাম আছে?

৪. কীভাবে প্রমাণীকরণ করবেন

  • REST নীতিগুলি অনুসরণ করে একটি API কী ভিত্তিক প্রমাণীকরণ দেখতে কেমন হবে?
  • কোনও আরইএসটি ক্লায়েন্টকে প্রমাণীকরণের সময় সেশনগুলি ব্যবহার করার বিরুদ্ধে কি শক্ত পয়েন্ট রয়েছে, তা ছাড়া এটি আরইএসটি নীতির লঙ্ঘন লঙ্ঘন? :) (এখানে কেবল অর্ধ মজা করা, সেশন ভিত্তিক প্রমাণীকরণ আমার বিদ্যমান অবকাঠামোটির সাথে ভাল খেলতে পারে))
web-services  rest 
— Pekka
সূত্র
13
@ ড্যানিয়েল, সম্পাদনার জন্য ধন্যবাদ "আমি আরও ক্রিয়াগুলি" ছিল একটি ইচ্ছাকৃত শ্লেষ, তবে আমি এখনকার মতো পড়তে আরও সহজ করে দিচ্ছি। :)
— পেক্কা
1
বিটিডাব্লু, ত্রুটির বর্ণনা সম্পর্কে। আমি প্রতিক্রিয়া শিরোনামে ত্রুটি বর্ণনা রেখে শেষ করেছি। 'ত্রুটির বিবরণ' নামে কেবল শিরোনাম যুক্ত করুন।
— Andrii Muzychuk
এটি অ্যাপ্লিকেশন সুরক্ষা প্রশ্নের মতো দেখতে আরও বেশি লাগে। অ্যাপ্লিকেশন সুরক্ষা আরএসটি-র সম্পর্কে নয়।
— নজর মেরজা
@ নাজারমারজা কীভাবে 1., 2. এবং 3. অ্যাপ্লিকেশন সুরক্ষা প্রশ্ন?
— পেক্কা

উত্তর:

620

আমি এই প্রশ্নটি কয়েক দিন দেরিতে লক্ষ্য করেছি, তবে আমি অনুভব করি যে আমি কিছু অন্তর্দৃষ্টি যুক্ত করতে পারি। আমি আশা করি এটি আপনার বিশ্রামের উদ্যোগের পক্ষে সহায়ক হতে পারে।

পয়েন্ট 1: আমি কি এটা ঠিক বুঝতে পারছি?

আপনি ঠিক বুঝতে পেরেছেন। এটি একটি রেস্টস্টুল আর্কিটেকচারের সঠিক উপস্থাপনা। আপনার বিশেষ্য এবং ক্রিয়াগুলি সংজ্ঞায়িত করতে আপনি উইকিপিডিয়া থেকে নিম্নলিখিত ম্যাট্রিক্সকে খুব সহায়ক বলে মনে করতে পারেন :

কোনও সংগ্রহ ইউআরআইয়ের সাথে কাজ করার সময় :http://example.com/resources/

  • জিইটি : সংগ্রহের সদস্যদের তালিকাভুক্ত করুন, আরও নেভিগেশনের জন্য তাদের সদস্য ইউআরআই দিয়ে পূর্ণ করুন। উদাহরণস্বরূপ, বিক্রয়ের জন্য সমস্ত গাড়ি তালিকাভুক্ত করুন।

  • পুট : অর্থটিকে "অন্য সংকলনের সাথে পুরো সংগ্রহটি প্রতিস্থাপন করুন" হিসাবে সংজ্ঞায়িত করা হয়েছে।

  • পোস্ট : সংগ্রহের মাধ্যমে আইডিটি স্বয়ংক্রিয়ভাবে নির্ধারিত হয় এমন সংকলনে একটি নতুন এন্ট্রি তৈরি করুন। তৈরি করা আইডি সাধারণত এই অপারেশনে ফিরে আসা ডেটার অংশ হিসাবে অন্তর্ভুক্ত থাকে।

  • মোছা: অর্থটিকে "পুরো সংগ্রহটি মুছুন" হিসাবে সংজ্ঞায়িত করা হয়েছে।

কোনও সদস্য ইউআরআইয়ের সাথে কাজ করার সময় :http://example.com/resources/7HOU57Y

  • জিইটি : উপযুক্ত এমআইএম টাইমে প্রকাশিত সংগ্রহের সম্বোধিত সদস্যের একটি উপস্থাপনা পুনরুদ্ধার করুন।

  • পুট : সংগ্রহের সম্বোধিত সদস্যকে আপডেট করুন বা নির্দিষ্ট আইডি দিয়ে এটি তৈরি করুন।

  • পোস্ট : সম্বোধিত সদস্যকে তার নিজস্বভাবে সংগ্রহ হিসাবে গণ্য করে এবং এটির একটি নতুন অধীনস্থ তৈরি করে।

  • মুছে দিন : সংগ্রহ সুরাহা সদস্য মুছে দিন।

পয়েন্ট 2: আমার আরও ক্রিয়া প্রয়োজন need

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

সক্রিয় / নিষ্ক্রিয় লগইন : আপনি যদি একটি নতুন অধিবেশন তৈরি করে থাকেন তবে আপনি "অধিবেশন "টিকে সংস্থান হিসাবে বিবেচনা করতে চাইতে পারেন। একটি নতুন অধিবেশন তৈরি করতে, http://example.com/sessions/শরীরে শংসাপত্রগুলির জন্য POST ব্যবহার করুন । এটির মেয়াদ শেষ করতে PUT বা একটি মোছা (সম্ভবত আপনি কোনও সেশনের ইতিহাস রাখার ইচ্ছা কিনা তার উপর নির্ভর করে) ব্যবহার করুন http://example.com/sessions/SESSION_ID।

পাসওয়ার্ড পরিবর্তন করুন: এবার সম্পদটি "ব্যবহারকারী"। http://example.com/users/USER_IDআপনার দেহে পুরানো এবং নতুন পাসওয়ার্ডগুলির জন্য একটি পুট লাগবে । আপনি "ব্যবহারকারী" রিসোর্সে অভিনয় করছেন, এবং পরিবর্তনের পাসওয়ার্ডটি কেবল একটি আপডেটের অনুরোধ। এটি একটি সম্পর্কিত ডেটাবেজে আপডেটের বিবৃতিতে বেশ অনুরূপ।

আমার প্রবৃত্তিটি কোনও ইউআরএল-এর মতো জিইটি কল করা /api/users/1/activate_login

এটি খুব মূল REST নীতিবিরোধী: HTTP ক্রিয়াগুলির সঠিক ব্যবহার। কোনও জিইটি অনুরোধের কখনই কোনও পার্শ্ব প্রতিক্রিয়া ছেড়ে দেওয়া উচিত নয়।

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

পয়েন্ট 3: ত্রুটি বার্তা এবং কোডগুলি কীভাবে ফিরে আসবে return

4xx বা 5XX HTTP স্থিতি কোডগুলি ত্রুটি বিভাগ হিসাবে বিবেচনা করুন। আপনি শরীরে ত্রুটিটি বিস্তারিতভাবে বর্ণনা করতে পারেন।

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

অন্যান্য বিভাগের ত্রুটিগুলি 4XX পরিবার হবে, যা সাধারণত ইঙ্গিত দেয় যে ক্লায়েন্টটি কিছু ভুল করেছে। বিশেষত, এই বিভাগের ত্রুটিগুলি সাধারণত ক্লায়েন্টকে নির্দেশ করে যে অনুরোধটি যেমন আছে তেমন চেষ্টা করার দরকার নেই কারণ এটি স্থায়ীভাবে ব্যর্থ হতে থাকবে। অর্থাৎ ক্লায়েন্টকে এই অনুরোধটি আবার চেষ্টা করার আগে কিছু পরিবর্তন করা দরকার। উদাহরণস্বরূপ, "রিসোর্স পাওয়া যায় নি" (HTTP 404) বা "ত্রুটিযুক্ত অনুরোধ" (HTTP 400) ত্রুটিগুলি এই বিভাগে আসবে।

পয়েন্ট 4: কীভাবে প্রমাণীকরণ করবেন

পয়েন্ট ১-এ উল্লিখিত হিসাবে, কোনও ব্যবহারকারীকে প্রমাণীকরণের পরিবর্তে আপনি একটি সেশন তৈরি করার বিষয়ে ভাবতে চাইতে পারেন। উপযুক্ত HTTP স্থিতি কোড (200: অ্যাক্সেস মঞ্জুরিপ্রাপ্ত বা 403: অ্যাক্সেস প্রত্যাখ্যান) সহ আপনাকে একটি নতুন "সেশন আইডি" ফিরিয়ে দেওয়া হবে।

তারপরে আপনি আপনার রেস্টহুল সার্ভারকে জিজ্ঞাসা করবেন: "আপনি কি এই সেশন আইডির জন্য আমাকে সংস্থান পেতে পারেন?"

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

— ড্যানিয়েল ভ্যাসালো
সূত্র
6
খুব ভাল, তবে PUTপাসওয়ার্ড পরিবর্তন করতে আপনার ব্যবহার সম্ভবত ভুল; PUTপুরো সংস্থান প্রয়োজন, সুতরাং আপনাকে HTTP (এবং তাই HATEOAS রেস্ট সহ) মেনে চলার জন্য সমস্ত ব্যবহারকারীর বৈশিষ্ট্য প্রেরণ করতে হবে। বরং, পাসওয়ার্ডটি পরিবর্তন করার জন্য একটি ব্যবহার করা উচিত PATCHবা POST।
— লরেন্স ডল
1
আমি মনে করি এই পোস্টটি নিখুঁত হবে যদি আপনি "পোষ্ট: সম্বোধনকৃত সদস্যকে তার নিজস্ব হিসাবে একটি সংগ্রহ হিসাবে বিবেচনা করেন এবং এটির একটি নতুন অধস্তন তৈরি করেন" তবে এটি আরও প্রসারিত হবে। উপায়। - গুগলিং এর অর্থ কী তা আমি খুঁজে পেয়েছি - এটি আপনার অন্যথায় দুর্দান্ত উত্তরের ব্যতিক্রম।
— মার্টিন কনেকনি
6
আমি একেবারে শেষ বাক্যটির সাথে একমত নই। আপনি কীভাবে রেস্ট স্টেটহীন, তা ব্যাখ্যা করছেন। একটি অধিবেশন তৈরি করতে লগ ইন করা, তারপর কিছু কাজ করার পরে সেশনটি শেষ করতে লগ আউট করা একটি রাষ্ট্রীয় এপিআইয়ের সেরা উদাহরণ।
— ব্র্যান্ডন
1
"এটি অত্যন্ত মূল REST নীতিবিরোধী: HTTP ক্রিয়াগুলির সঠিক ব্যবহার Any - আপনি যদি সংস্থানটির জন্য হিট গণনা বজায় রাখতে চান তবে কী হবে?
— বোবিলেেক্স
1
এই নিবন্ধটি আপনার প্রশ্নের উত্তর দেওয়া উচিত। saipraveenblog.wordpress.com/2014/09/29/rest-api-best-practices
— java_geek
79

সোজা কথায়, আপনি এটি পুরোপুরি পিছনে করছেন।

আপনার কোন ইউআরএলগুলি ব্যবহার করা উচিত তা থেকে আপনার কাছে আসা উচিত নয়। আপনার সিস্টেমে কী কী সংস্থান প্রয়োজন এবং আপনি কীভাবে সেই সংস্থানগুলি উপস্থাপন করবেন এবং সংস্থানসমূহ এবং প্রয়োগের স্থিতির মধ্যে মিথস্ক্রিয়া হয়েছে তা একবার স্থির করে নিলে URL গুলি কার্যকরভাবে "বিনামূল্যে" আসবে।

রয় ফিল্ডিংয়ের উদ্ধৃতি দিতে

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

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

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

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

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

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

তবে, এক্সএইচটিএমএল মানব ওয়েবে খুব ভাল (স্পষ্টতই) কাজ করে যেখানে ওয়েব ব্রাউজারগুলি এবং রেন্ডারিং খুব গুরুত্বপূর্ণ।

আপনার আবেদন আপনাকে এই ধরণের সিদ্ধান্তে পরিচালিত করবে।

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

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

উদাহরণস্বরূপ, আপনার থাকতে পারে:

<link href="http://example.com/users" rel="users" type="application/xml+usercollection"/>
<link href="http://example.com/users?search" rel="search" type="application/xml+usersearchcriteria"/>

আপনার ডকুমেন্টেশনগুলি "ব্যবহারকারীদের" নামক rel ক্ষেত্র এবং "অ্যাপ্লিকেশন / এক্সএমএল + আপনার ব্যবহারকারী" এর মিডিয়া ধরণের বিষয়ে কথা বলবে।

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

এটি কারণ "ব্যবহারকারীদের" সম্পর্কের জন্য, সেই লিঙ্কটি ব্যবহারকারীদের সংগ্রহের বিষয়ে কথা বলছে, এবং আপনি সংগ্রহের সাথে কাজ করার জন্য অভিন্ন ইন্টারফেসটি ব্যবহার করতে পারেন (তাদের সমস্তটি পুনরুদ্ধার করতে জিইটি করুন, সেগুলি মুছতে মুছুন ইত্যাদি))

আপনি যদি এই ইউআরএল পোস্ট করেন তবে আপনাকে একটি "অ্যাপ্লিকেশন / এক্সএমএল + ব্যবহারকারীক্লিকেশন" নথিটি পাস করতে হবে যা সম্ভবত ডকুমেন্টের মধ্যে কেবলমাত্র একক ব্যবহারকারীর উদাহরণস্বরূপ থাকবে যাতে আপনি ব্যবহারকারীকে যুক্ত করতে পারেন বা নাও হতে পারে এতে কয়েকটি যুক্ত করতে পারেন একদা. সম্ভবত আপনার ডকুমেন্টেশনগুলি পরামর্শ দেবে যে আপনি সংগ্রহের পরিবর্তে কেবল একটি একক ব্যবহারকারীর পাস করতে পারেন।

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

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

ক্লায়েন্টকে কীভাবে মিডিয়া প্রকারের কৌশল এবং ব্যাখ্যা করতে হবে তা জানতে হবে তবে এটি কোথায় যায় সেদিকে খুব বেশি যত্নের প্রয়োজন নেই।

এই দুটি লিঙ্কগুলি ক্লায়েন্টের দৃষ্টিতে শব্দার্থগতভাবে অভিন্ন:

<link href="http://example.com/users?search" rel="search" type="application/xml+usersearchcriteria"/>
<link href="http://example.com/AW163FH87SGV" rel="search" type="application/xml+usersearchcriteria"/>

সুতরাং, আপনার সংস্থানগুলিতে ফোকাস করুন। অ্যাপ্লিকেশনটিতে তাদের রাষ্ট্রের রূপান্তরগুলিতে মনোনিবেশ করুন এবং এটি কীভাবে সেরা অর্জন করেছে।

— উইল হার্টুং
সূত্র
1
এই খুব গভীর উত্তরের জন্য ধন্যবাদ উইল। বেশ কয়েকটি পয়েন্ট নেওয়া হয়েছে। আমি বুঝতে পেরেছি যে "URL টির মতো দেখতে" থেকে পরিকল্পনা করা অন্যদিকে এটি করছে এবং আমিও উত্স থেকে পাশ থেকে পরিকল্পনা করছি। কেবলমাত্র খেলতে ইউআরএল থাকা আমার ধারণাটি বুঝতে আরও সহজ করে তোলে। এটি এমন হতে পারে যে আমার প্রয়োজনীয়তা এমন কোনও সিস্টেমের সাথে পূরণ করা যেতে পারে যা আপনি এখানে এটি সংজ্ঞায়িত করার সাথে সাথে 100% আরএসটি নীতি অনুসরণ করেন না। আমি প্রতিটি সংস্থার জন্য প্রয়োজনীয়তার একটি সম্পূর্ণ তালিকা বের করব, আমার ধারণা আমি তখনই সিদ্ধান্ত নিতে সক্ষম হব। চিয়ার্স।
— পেক্কা
30

পুনরায় 1 : এটি এখন পর্যন্ত ঠিক দেখাচ্ছে। "201 তৈরি করা" স্থিতি কোড সহ পোষ্টের প্রতিক্রিয়ার অংশ হিসাবে একটি "অবস্থান:" শিরোনামে নতুন তৈরি করা ব্যবহারকারীর ইউআরআই ফিরিয়ে দিতে ভুলবেন না।

পুনরায় 2: জিইটি এর মাধ্যমে অ্যাক্টিভেশন করা একটি খারাপ ধারণা এবং ইউআরআইতে ক্রিয়াটি সহ একটি ডিজাইনের গন্ধ। আপনি জিইটি-তে কোনও ফর্ম ফিরিয়ে দেওয়ার বিষয়ে বিবেচনা করতে পারেন। কোনও ওয়েব অ্যাপ্লিকেশনে, এটি জমা দেওয়ার বোতাম সহ একটি HTML ফর্ম হবে; এপিআই ব্যবহারের ক্ষেত্রে, আপনি অ্যাকাউন্টটি সক্রিয় করতে পিআউটিতে একটি ইউআরআই রয়েছে এমন একটি উপস্থাপনা ফিরে আসতে পারেন। অবশ্যই আপনি এই ইউআরআই পোস্টার / ব্যবহারকারীদের প্রতিক্রিয়াতেও অন্তর্ভুক্ত করতে পারেন users PUT ব্যবহার করে আপনার অনুরোধটি আদর্শবান হওয়ার বিষয়টি নিশ্চিত করবে, অর্থাৎ ক্লায়েন্ট সাফল্যের বিষয়ে নিশ্চিত না হলে এটি নিরাপদে আবার পাঠানো যেতে পারে। সাধারণভাবে, কী কী সংস্থানগুলি নিয়ে আপনি আপনার ক্রিয়াকলাপগুলিকে রূপান্তর করতে পারেন সে সম্পর্কে চিন্তা করুন ("ক্রিয়াপদের নামকরণ" বাছাই করুন)। আপনার সুনির্দিষ্ট ক্রিয়াটি কোন পদ্ধতির সাথে সবচেয়ে নিবিড়ভাবে সংযুক্ত রয়েছে তা নিজেকে জিজ্ঞাসা করুন। যেমন চেঞ্জ_পাসওয়ার্ড -> পুট; নিষ্ক্রিয় -> সম্ভবত মুছে ফেলুন; add_credit -> সম্ভবত পোস্ট করুন বা পুট করুন।

পুনরায় 3. নতুন স্ট্যাটাস কোডগুলি উদ্ভাবন করবেন না, যদি না আপনি বিশ্বাস করেন যে তারা এতই জেনেরিক তবে তারা বিশ্বব্যাপী মানসম্পন্ন হওয়ার যোগ্যতা অর্জন করবে। উপলব্ধ সবচেয়ে উপযুক্ত স্থিতি কোড ব্যবহার করার জন্য কঠোর চেষ্টা করুন (আরএফসি 2616 এ সমস্ত সম্পর্কে পড়ুন)। প্রতিক্রিয়া বডিতে অতিরিক্ত তথ্য অন্তর্ভুক্ত করুন। আপনি যদি সত্যই সত্যই নিশ্চিত হন যে আপনি একটি নতুন স্ট্যাটাস কোড উদ্ভাবন করতে চান তবে আবার চিন্তা করুন; আপনি যদি এখনও এটি বিশ্বাস করেন তবে কমপক্ষে সঠিক বিভাগটি বেছে নেওয়ার বিষয়টি নিশ্চিত করুন (1xx -> ঠিক আছে, 2XX -> তথ্যমূলক, 3xx -> পুনর্নির্দেশ; 4xx-> ক্লায়েন্ট ত্রুটি, 5xx -> সার্ভার ত্রুটি)। আমি কি উল্লেখ করেছি যে নতুন স্ট্যাটাস কোড উদ্ভাবন করা একটি খারাপ ধারণা?

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

— স্টেফান তিলকভ
সূত্র
ইউআরএলগুলিতে এপিআই কীগুলি না রাখার বিষয়ে আপনি আলোচনা করতে পারেন? প্রক্সি লগগুলিতে এগুলি দৃশ্যমান হওয়ার কারণে কি? কীগুলি যদি সময়ভিত্তিক ক্ষণস্থায়ী হয়? এইচটিটিপিএস ব্যবহার করা হলে কী হবে?
— মাইকচিনকেলে
4
স্পিরিটি লঙ্ঘন করা ছাড়াও (ইউআরআইগুলিকে জিনিসগুলি সনাক্ত করা উচিত), এর প্রধান পরিণতি হ'ল এটি ক্যাচিংকে ধ্বংস করে দেয়।
— স্টিফান তিলকভ
22

1. আপনার সংস্থানগুলি কীভাবে ডিজাইন করবেন, আইএমএইচও সম্পর্কে সঠিক ধারণা পেয়েছেন। আমি কোন জিনিস পরিবর্তন করব না।

২. আরও ক্রিয়া সহ HTTP প্রসারিত করার চেষ্টা করার পরিবর্তে, আপনার প্রস্তাবিত ক্রিয়াগুলি বেসিক এইচটিটিপি পদ্ধতি এবং সংস্থানগুলির ক্ষেত্রে কমে যেতে পারে তা বিবেচনা করুন। উদাহরণস্বরূপ, একটি activate_loginক্রিয়াপদের পরিবর্তে আপনি এই জাতীয় সংস্থান স্থাপন করতে পারেন: /api/users/1/login/activeএটি একটি সাধারণ বুলিয়ান। একটি লগইন সক্রিয় করতে, PUTসেখানে কেবলমাত্র একটি ডকুমেন্ট যা 'সত্য' বা 1 বা যাই হোক না কেন বলে। নিষ্ক্রিয় করতে, PUTসেখানে একটি নথি যা খালি বা 0 বা মিথ্যা বলে।

একইভাবে, পরিবর্তন অথবা সেট পাসওয়ার্ড, ঠিক না PUTs করা /api/users/1/password।

যখনই আপনাকে কিছু যুক্ত করতে হবে (ক্রেডিটের মতো) এর শর্তে ভাবেন POST। উদাহরণস্বরূপ, আপনি POSTসংস্থান /api/users/1/creditsকরতে সংখ্যার ক্রেডিট সংখ্যা সম্বলিত কোনও বডি সহ এমন কোনও সংস্থান করতে পারেন। PUTএকই সংস্থানটিতে একটি যোগ করার পরিবর্তে মানটিকে ওভাররাইট করতে ব্যবহার করা যেতে পারে। একটি POSTশরীরের একটি ঋণাত্মক সংখ্যা সঙ্গে বিয়োগ হবে, ইত্যাদি।

৩. আমি বেসিক এইচটিটিপি স্থিতি কোডগুলি প্রসারিত করার বিরুদ্ধে দৃ strongly়ভাবে পরামর্শ দেব। আপনি যদি আপনার পরিস্থিতির সাথে মেলে এমন কোনওটি খুঁজে না পান তবে নিকটতমটিকে বেছে নিন এবং ত্রুটির বিশদটি প্রতিক্রিয়া শিবিরে রাখুন। এছাড়াও, মনে রাখবেন যে এইচটিটিপি শিরোনামগুলি এক্সটেনসিবল; আপনার অ্যাপ্লিকেশনটি আপনার পছন্দ মতো সমস্ত কাস্টম শিরোনামকে সংজ্ঞায়িত করতে পারে। একটি অ্যাপ্লিকেশন যা আমি কাজ করেছি, উদাহরণস্বরূপ, 404 Not Foundএকাধিক পরিস্থিতিতে একটি ফিরে আসতে পারে । ক্লায়েন্টটি কারণে প্রতিক্রিয়া বডিকে বিশ্লেষণ করার পরিবর্তে আমরা সবেমাত্র একটি নতুন শিরোনাম যুক্ত করেছি, X-Status-Extendedএতে আমাদের মালিকানাধীন স্থিতি কোড এক্সটেনশন রয়েছে। সুতরাং আপনি যেমন একটি প্রতিক্রিয়া দেখতে পাবেন:

HTTP/1.1 404 Not Found    
X-Status-Extended: 404.3 More Specific Error Here

ওয়েব ব্রাউজারের মতো এইচটিটিপি ক্লায়েন্ট এখনও নিয়মিত 404 কোডটি দিয়ে কী করবে তা জানতে পারবে X-Status-Extendedএবং আরও সুনির্দিষ্ট HTTP ক্লায়েন্ট আরও নির্দিষ্ট তথ্যের জন্য শিরোনামটি দেখতে বেছে নিতে পারে ।

4. প্রমাণীকরণের জন্য, আমি যদি আপনি পারেন তবে HTTP প্রমাণীকরণ ব্যবহার করার পরামর্শ দিচ্ছি। তবে আইএমএইচও আপনার পক্ষে যদি আরও সহজ হয় তবে কুকি-ভিত্তিক প্রমাণীকরণ ব্যবহারে কোনও ভুল নেই।

— friedo
সূত্র
4
বৃহত্তর সংস্থার ছোট অংশগুলিতে কাজ করতে "বর্ধিত" সংস্থান ব্যবহারের সুক্ষ ধারণা।
— 28:41
1
কুকিজ এইচটিটিপি / আরএসটি-তে বৈধ, তবে সার্ভারের কুকিটিকে রাষ্ট্র হিসাবে সংরক্ষণ করা উচিত নয় (সুতরাং সেশন হিসাবে নয়)। কুকি একটি এইচএমএএকের মতো একটি মান সংরক্ষণ করতে পারে, তবে অন্য কোথাও রাজ্যটি না দেখেই তা বিচ্ছিন্ন করা যেতে পারে।
— ব্রুস অলডারসন
14

বিশ্রামের মূল বিষয়গুলি

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

তাই আরইএসটি ক্লায়েন্ট এবং আরইএসটি পরিষেবার মধ্যে একটি চুক্তি রয়েছে। আপনি যদি অন্তর্নিহিত প্রোটোকল হিসাবে এইচটিটিপি ব্যবহার করেন তবে নিম্নলিখিত মানগুলি চুক্তির অংশ:

  • HTTP 1.1
    • পদ্ধতির সংজ্ঞা
    • স্থিতি কোড সংজ্ঞা
    • ক্যাশে নিয়ন্ত্রণ শিরোনাম
    • গ্রহণ করুন এবং কন্টেন্ট-টাইপ শিরোনাম
    • লেখক শিরোনাম
  • আইআরআই (utf8 ইউআরআই )
  • শরীর (একটি বাছাই)
    • নিবন্ধভুক্ত অ্যাপ্লিকেশন নির্দিষ্ট MIME প্রকার, যেমন গোলকধাঁধা + এক্সএমএল
    • বিক্রেতার নির্দিষ্ট MIME টাইপ, যেমন vnd.github + json
    • জেনেরিক মাইম টাইপ সাথে
      • আবেদন নির্দিষ্ট RDF vocab, যেমন LD + + JSON & Hydra , schema.org
      • অ্যাপ্লিকেশন নির্দিষ্ট প্রোফাইল, উদাহরণস্বরূপ হল + জসন এবং প্রোফাইল লিঙ্ক প্যারাম (আমার ধারণা)
  • হাইপার-লিঙ্ক
    • এগুলিকে কী থাকতে হবে (একটি বাছাই করুন)
      • লিঙ্ক শিরোনাম প্রেরণ
      • হাইপারমিডিয়া প্রতিক্রিয়া প্রেরণ করা হচ্ছে, যেমন এইচটিএমএল, পরমাণু + এক্সএমএল, হাল + জসন, এলডি + জেসন এবং হাইড্রা ইত্যাদি ...
    • শব্দার্থবিদ্যা
      • IANA লিঙ্ক সম্পর্ক এবং সম্ভবত কাস্টম লিঙ্ক সম্পর্ক ব্যবহার করুন
      • একটি অ্যাপ্লিকেশন নির্দিষ্ট আরডিএফ ভোকাব ব্যবহার করুন

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

আপনার প্রশ্নের উত্তর দিতে

  1. হ্যাঁ, এটা হতে পারে।

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

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

    আমরা খুব ভাল আইআরআই পছন্দ করি কেন এটি খুব সহজ /users/123/password; সার্ভারে রাউটিং লজিকটি লেখা যখন আপনি কেবল আইআরআই পড়েন তখন তা সহজেই লেখা সহজ হয়।

  2. আপনার PUT, প্যাচ, বিকল্প, এবং আরও অনেক ক্রিয়া আছে, তবে আপনার এর বেশি প্রয়োজন নেই ... নতুন ক্রিয়া যুক্ত করার পরিবর্তে আপনাকে কীভাবে নতুন সংস্থান যুক্ত করতে হবে তা শিখতে হবে।

    activate_login -> PUT /login/active true deactivate_login -> PUT /login/active false change_password -> PUT /user/xy/password "newpass" add_credit -> POST /credit/raise {details: {}}

    (রাষ্ট্রবিহীন সীমাবদ্ধতার কারণে লগইনটি আরআরএসটি দৃষ্টিভঙ্গি থেকে বোঝা যায় না))

  3. আপনার ব্যবহারকারীরা সমস্যাটি কেন বিদ্যমান তা নিয়ে চিন্তা করেন না। তারা কেবলমাত্র সাফল্য বা ত্রুটি আছে কিনা তা জানতে চায় এবং সম্ভবত একটি ত্রুটি বার্তা যা তারা বুঝতে পারে, উদাহরণস্বরূপ: "দুঃখিত, তবে আমরা আপনার পোস্টটি সংরক্ষণ করতে পারিনি।", ইত্যাদি ...

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

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

    তৃতীয় পক্ষের ক্লায়েন্টটি যদি ব্যবহারকারী প্রধান ক্লায়েন্টটি ব্যবহার করে এটিতে অ্যাক্সেস দেয় তবে অ্যাক্সেস টোকেন পায়। এর পরে তৃতীয় পক্ষের ক্লায়েন্ট প্রতিটি অনুরোধের সাথে অ্যাক্সেস টোকেন প্রেরণ করে। আরও জটিল সমাধান রয়েছে, উদাহরণস্বরূপ, আপনি প্রতিটি একক অনুরোধে স্বাক্ষর করতে পারেন, ইত্যাদি আরও তথ্যের জন্য OAuth ম্যানুয়ালটি পরীক্ষা করে দেখুন।

সংশ্লিষ্ট সাহিত্য

— inf3rno
সূত্র
11

আপনি বলেছেন যে উদাহরণগুলির জন্য আমি নিম্নলিখিতগুলি ব্যবহার করব:

activate_login

POST /users/1/activation

deactivate_login

DELETE /users/1/activation

change_password

PUT /passwords (এটি ধরে নিচ্ছে যে ব্যবহারকারী প্রমাণীকৃত)

add_credit

POST /credits (এটি ধরে নিচ্ছে যে ব্যবহারকারী প্রমাণীকৃত)

ত্রুটিগুলির জন্য আপনি অনুরোধটি যে ফর্ম্যাটটিতে পেয়েছেন তাতে শরীরে ত্রুটিটি ফিরে আসবে, তাই যদি আপনি গ্রহণ করেন:

DELETE /users/1.xml

আপনি এক্সএমএলে প্রতিক্রিয়াটি আবার পাঠাতে চাইবেন, জেএসএন ইত্যাদির ক্ষেত্রেও এটি সত্য হবে ...

প্রমাণীকরণের জন্য আপনার http প্রমাণীকরণ ব্যবহার করা উচিত।

— jonnii
সূত্র
1
আমি createইউআরআই এর অংশ হিসাবে ব্যবহার করব না (মনে রাখবেন ইউআরআই বিশেষ্য হওয়া উচিত, এবং এইচটিটিপি পদ্ধতিগুলি এমন ক্রিয়াগুলি হওয়া উচিত যা সেই বিশেষ্যগুলিতে পরিচালিত হয়।) পরিবর্তে, আমার কাছে এমন একটি সংস্থান থাকবে /users/1/activeযা একটি সাধারণ বুলিয়ান হতে পারে, এবং এটি হতে পারে এই সংস্থানটিতে 1 বা 0 রেখে পাট সেট করে।
— ফ্রেডো
আপনি ঠিক বলেছেন, আমি তৈরি / তৈরি করেছি। এটি কেবল সিঙ্গলটন রিসোর্সে পোস্ট হওয়া উচিত।
— jonnii
3
আমি activationইউআরআই তে ব্যবহার করব না , যদি না আপনি স্পষ্টভাবে এর নামে কোনও সংস্থান পরিচালনা এবং পরিচালনা করবেন /users/1/activation। এতে একটি জিইটি কী করবে? একটি পুট কি করে? এটি নিশ্চিতভাবে আমার কাছে অনুভূত হয় যে আপনি ইউআরআই পরীক্ষা করছেন। এছাড়াও, বিষয়বস্তুর ধরণের আলোচনার ক্ষেত্রে এটিও প্রায়শই ইউআরআই থেকে সর্বাধিক ভাল থাকে এবং পছন্দ মতো শিরোনাম .োকানো হয় Accept।
— চিজো
6
  1. আপনি যখন জানেন না যে নতুন সংস্থানটি ইউআরআই দেখতে কেমন হবে (আপনি নতুন ব্যবহারকারী তৈরি করবেন, অ্যাপ্লিকেশনটি নতুন আইডিটি এটির আইডি নির্ধারণ করবে), আপডেট করার জন্য বা সংস্থান তৈরি করার জন্য PUT যা আপনি জানেন যে তারা কীভাবে উপস্থাপিত হতে চলেছে (উদাহরণস্বরূপ : পুট / মায়িফাইলস / থিসিস্মিনিউফিল.টেক্সট)
  2. বার্তা শরীরে ত্রুটি বর্ণনা ফিরে
  3. আপনি HTTP প্রমাণীকরণ ব্যবহার করতে পারেন (এটি পর্যাপ্ত থাকলে) ওয়েব পরিষেবাদি স্টেটল হওয়া উচিত
— Arjan
সূত্র
5

আমি প্রস্তাব দেব (প্রথম পাস হিসাবে) যা PUTকেবল বিদ্যমান সত্তা আপডেট করার জন্য ব্যবহার করা উচিত। POSTনতুন তৈরির জন্য ব্যবহার করা উচিত। অর্থাত

/api/users     when called with PUT, creates user record

আমার কাছে ঠিক মনে হচ্ছে না তবে আপনার প্রথম বিভাগের বাকি অংশ (পুনরায় ক্রিয়া ব্যবহার) যৌক্তিক দেখাচ্ছে।

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

ভার্বোজ, তবে HTTP 1.1 পদ্ধতির স্পেসিফিকেশন থেকে http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html এ অনুলিপি করা হয়েছে

9.3 জিইটি

জিইটি পদ্ধতিটির অর্থ অনুরোধ-ইউআরআই দ্বারা চিহ্নিত যে কোনও তথ্য (সত্তার আকারে) সনাক্ত করা। যদি অনুরোধ-ইউআরআই কোনও ডেটা উত্পাদনকারী প্রক্রিয়াটিকে বোঝায়, তবে এটি উত্পাদিত ডেটা যা প্রতিক্রিয়াতে সত্তা হিসাবে ফিরে আসবে এবং প্রক্রিয়াটির উত্স পাঠ্য নয়, যদি না যে পাঠ্যটি প্রক্রিয়াটির আউটপুট না ঘটে।

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

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

একটি জিইটি অনুরোধের প্রতিক্রিয়া ক্যাশেযোগ্য যদি কেবল এবং যদি এটি বিভাগে 13 টিতে বর্ণিত এইচটিটিপি ক্যাচিংয়ের প্রয়োজনীয়তা পূরণ করে।

ফর্মগুলির জন্য ব্যবহারের সময় সুরক্ষা বিবেচনার জন্য বিভাগ 15.1.3 দেখুন।

9.5 পোস্ট

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

  - Annotation of existing resources;
  - Posting a message to a bulletin board, newsgroup, mailing list,
    or similar group of articles;
  - Providing a block of data, such as the result of submitting a
    form, to a data-handling process;
  - Extending a database through an append operation.

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

পোস্ট পদ্ধতি দ্বারা সম্পাদিত ক্রিয়াকলাপের ফলে এমন কোনও সংস্থান দেখা যায় না যা কোনও ইউআরআই দ্বারা চিহ্নিত করা যায়। এই ক্ষেত্রে, 200 (ঠিক আছে) বা 204 (কোনও বিষয়বস্তু নয়) উপযুক্ত প্রতিক্রিয়ার স্থিতি, প্রতিক্রিয়ার ফলাফলটি বর্ণনা করে এমন কোনও সত্তা অন্তর্ভুক্ত কিনা তা নির্ভর করে।

যদি উত্স সার্ভারে কোনও উত্স তৈরি করা থাকে, তবে প্রতিক্রিয়াটি 201 (হওয়া উচিত) হওয়া উচিত এবং এতে একটি সত্তা থাকতে হবে যা অনুরোধের স্থিতি বর্ণনা করে এবং নতুন সংস্থান এবং একটি অবস্থান শিরোনাম (বিভাগ 14.30 দেখুন)।

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

পোষ্টটি 8.2 বিভাগে বর্ণিত বার্তা প্রেরণের প্রয়োজনীয়তাগুলি মেনে চলা উচিত।

সুরক্ষা বিবেচনার জন্য বিভাগ 15.1.3 দেখুন।

9.6 পুট

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

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

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

এটি একটি 301 (স্থায়ীভাবে সরানো) প্রতিক্রিয়া পাঠাতে হবে; ইউজার এজেন্ট মাই এর পরে অনুরোধটি পুনর্নির্দেশ করতে হবে কিনা সে সম্পর্কে নিজস্ব সিদ্ধান্ত নিতে পারে।

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

HTTP / 1.1 কোনও PUT পদ্ধতি কীভাবে কোনও উত্সের সার্ভারের অবস্থাকে প্রভাবিত করে তা নির্ধারণ করে না।

পুট অনুরোধ করা আবশ্যক মেসেজ ট্রান্সমিশন প্রয়োজনীয়তা বিভাগ 8.2।

নির্দিষ্ট কোনও সত্তা-শিরোনামের জন্য অন্যথায় নির্দিষ্ট না করা পর্যন্ত, পুট অনুরোধে সত্তা-শিরোনামগুলি পুট দ্বারা তৈরি বা সংশোধিত সংস্থার উপর প্রয়োগ করা উচিত।

9.7 মুছুন

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

একটি সফল প্রতিক্রিয়া 200 (ঠিক আছে) হওয়া উচিত যদি প্রতিক্রিয়াটির স্থিতি বর্ণনা করে এমন একটি সত্তা অন্তর্ভুক্ত থাকে, 202 (স্বীকৃত) যদি ক্রিয়াটি এখনও কার্যকর করা হয়নি, বা 204 (কোনও বিষয়বস্তু নেই) যদি পদক্ষেপ কার্যকর করা হয়েছে তবে প্রতিক্রিয়াটি অন্তর্ভুক্ত না একটি সত্তা.

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

— gahooa
সূত্র
2

REST রিটার্ন কোডগুলি সম্পর্কে: এটি ভুল HTTP প্রোটোকল কোড এবং REST ফলাফলগুলি মিশ্রিত ।

যাইহোক, আমি অনেকগুলি প্রয়োগগুলি সেগুলিকে মিশ্রিত করতে দেখেছি এবং অনেক বিকাশকারী আমার সাথে একমত হতে পারে না।

এইচটিটিপি রিটার্ন কোডগুলি HTTP Requestনিজের সাথে সম্পর্কিত । হাইপারটেক্সট ট্রান্সফার প্রোটোকল অনুরোধটি ব্যবহার করে একটি আরইএসটি কল করা হয় এবং এটি নিজেই অনুরোধ করা আরআরইএসটি পদ্ধতির চেয়ে কম স্তরে কাজ করে। REST হ'ল একটি ধারণা / পন্থা এবং এর আউটপুট একটি ব্যবসায়িক / যৌক্তিক ফলাফল, যখন এইচটিটিপি রেজাল্ট কোডটি পরিবহন ।

উদাহরণস্বরূপ, আপনি যখন / ব্যবহারকারীদের / কল করে তখন "404 পাওয়া যায় না" ফিরে আসা, কারণ এর অর্থ হতে পারে:

  • ইউআরআই ভুল (HTTP)
  • কোনও ব্যবহারকারীকে পাওয়া যায়নি (REST)

"403 নিষিদ্ধ / অ্যাক্সেস অস্বীকৃত" এর অর্থ হতে পারে:

  • বিশেষ অনুমতি প্রয়োজন। ব্রাউজারগুলি ব্যবহারকারী / পাসওয়ার্ড জিজ্ঞাসা করে এটি পরিচালনা করতে পারে। (HTTP-)
  • সার্ভারে ভুল অ্যাক্সেস অনুমতি কনফিগার করা হয়েছে। (HTTP-)
  • আপনাকে অনুমোদন দেওয়া দরকার (REST)

এবং তালিকাটি '500 সার্ভার ত্রুটি' (একটি অ্যাপাচি / এনগিনেক্স এইচটিটিপি নিক্ষেপ ত্রুটি বা আরএসটি-তে একটি ব্যবসায় বাধা ত্রুটি) বা অন্যান্য এইচটিটিপি ত্রুটি ইত্যাদি দিয়ে চালিয়ে যেতে পারে ...

কোড থেকে, এটি ব্যর্থতার কারণ, একটি HTTP (পরিবহন) ব্যর্থতা বা একটি REST (যৌক্তিক) ব্যর্থতা কী তা বোঝা শক্ত।

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

এর পরিবর্তে আপনি 200 টি এইচটিপি কোড এবং খালি অ্যারে / অবজেক্ট সহ কেবল একটি জেএসএন, বা সম্পাদিত অপারেশন স্থিতি সম্পর্কে অবহিত করতে একটি বুল ফলাফল / সাফল্যের পতাকা ব্যবহার করতে পারেন।

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

উইকি থেকে :

জুলাই 2004 সালে, যুক্তরাজ্যের টেলিকম সরবরাহকারী বিটি গ্রুপ ক্লিনফিড কনটেন্ট ব্লকিং সিস্টেম মোতায়েন করেছে, যা ইন্টারনেট ওয়াচ ফাউন্ডেশন দ্বারা সম্ভাব্য অবৈধ হিসাবে চিহ্নিত সামগ্রীর জন্য কোনও অনুরোধে 404 ত্রুটি প্রদান করে। অন্যান্য আইএসপি একই পরিস্থিতিতে একটি HTTP 403 "নিষিদ্ধ" ত্রুটি প্রদান করে। সেন্সরশিপ গোপন করার উপায় হিসাবে নকল 404 ত্রুটি নিয়োগের অনুশীলন থাইল্যান্ড এবং তিউনিসিয়ায়ও প্রকাশিত হয়েছে। তিউনিসিয়ায়, যেখানে ২০১১ সালের বিপ্লবের আগে সেন্সরশিপ কঠোর ছিল, লোকেরা নকল ৪০৪ ত্রুটির প্রকৃতি সম্পর্কে সচেতন হয়েছিল এবং "অমার্শন ৪০৪" নামে একটি কাল্পনিক চরিত্র তৈরি করেছিলেন, যিনি "অদৃশ্য সেন্সর" উপস্থাপন করেন।

— Marcodor
সূত্র
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.