রেস্ট এপিআই - পুট ডিলিট পোষ্ট পাবেন কেন?


155

সুতরাং, আমি REST এপিআই তৈরির বিষয়ে কিছু নিবন্ধ দেখছিলাম। এবং তাদের মধ্যে কিছু HTTP অনুরোধের সমস্ত ধরণের ব্যবহারের পরামর্শ দেয়: যেমন PUT DELETE POST GET। আমরা উদাহরণস্বরূপ index.php তৈরি করব এবং এপিআই লিখব:

$method = $_SERVER['REQUEST_METHOD'];
$request = split("/", substr(@$_SERVER['PATH_INFO'], 1));

switch ($method) {
  case 'PUT':
    ....some put action.... 
    break;
  case 'POST':
    ....some post action.... 
    break;
  case 'GET':
    ....some get action.... 
    break;
  case 'DELETE':
    ....some delete action.... 
    break;
}

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

আমি কিছু অনুপস্থিত করছি?

আপডেট 1:

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


4
জেএসএন পে-লোড কেন জোর করবেন? যদি কোন জেএসওএন না থাকে এবং এটি একটি সাধারণ পুরানো জিইটি?
মাইক ডিসিমোন

উত্তর:


200

আর ই উপস্থাপক এস টেট টি ট্রান্সফার ধারণাটি সহজতম উপায়ে ডেটা অ্যাক্সেস করার বিষয়ে নয়।

আপনি JSON অ্যাক্সেস করার জন্য পোস্ট অনুরোধগুলি ব্যবহার করার পরামর্শ দিয়েছেন, যা ডেটা অ্যাক্সেস / ম্যানিপুলেট করার জন্য একদম বৈধ উপায়।

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

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

GET: /cars/make/chevrolet

সম্ভবত চবি গাড়িগুলির একটি তালিকা ফেরত দিতে চলেছে। একটি ভাল REST API এমনকি মত querystring মধ্যে কিছু আউটপুট অপশন নিগমবদ্ধ পারে ?output=jsonবা ?output=htmlযা অ্যাকসেসর সিদ্ধান্ত নিতে সম্বন্ধে কি ধরনের ফর্ম্যাটে তথ্য এনকোড করা উচিত সম্ভব হবে।

কীভাবে বিশ্রাম এপিআই মধ্যে যুক্তিসঙ্গতভাবে ইনকর্পোরেট ডেটা টাইপ চিন্তা একটি বিট পর, আমি যে সবচেয়ে ভালো উপায় স্পষ্টভাবে ডেটা প্রকার যেমন ইতিমধ্যে বিদ্যমান ফাইল এক্সটেনশন মাধ্যমে হবে পর্যবসিত করে থাকেন .js, .json, .html, অথবা .xml। অনুপস্থিত ফাইল এক্সটেনশনটি যে কোনও ফর্ম্যাটটিতে ডিফল্ট (যেমন JSON) এ ডিফল্ট হবে; সমর্থিত নয় এমন একটি ফাইল এক্সটেনশান 501 Not Implementedস্থিতি কোডটি ফিরিয়ে দিতে পারে ।

আরেকটি উদাহরণ:

POST: /cars/
{ make:chevrolet, model:malibu, colors:[red, green, blue, grey] }

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

এখন আমাদের আদর্শবোধের ইস্যুটির দিকে এগিয়ে যাওয়া দরকার । সাধারণত REST HTTP- র মাধ্যমে CRUD প্রয়োগ করে। HTTP- র ব্যবহার GET, PUT, POSTএবং DELETEঅনুরোধের জন্য।

আরইএসটি-র একটি খুব সরল বাস্তবায়ন নিম্নলিখিত সিআরইউডি ম্যাপিং ব্যবহার করতে পারে :

Create -> Post
Read   -> Get
Update -> Put
Delete -> Delete

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

এর অর্থ একটি অনুরোধ যেমন:

Delete: /cars/oldest

আসলে হিসাবে প্রয়োগ করা যেতে পারে:

Post: /cars/oldest?action=delete

যেহেতু

Delete: /cars/id/123456

আপনি একবার কল করলে বা আপনি এটি একবার 1000 বার কল করলে একই সার্ভারের স্থিতিতে ফলাফল হয়।

oldestআইটেমটি অপসারণ পরিচালনা করার একটি ভাল উপায় হ'ল অনুরোধ করা হবে:

Get: /cars/oldest

এবং IDএকটি deleteঅনুরোধ করতে ফলাফল তথ্য থেকে ব্যবহার করুন :

Delete: /cars/id/[oldest id]

এই পদ্ধতির একটি সমস্যা হ'ল যদি অনুরোধ করা হয় এবং কখন জারি করা হয় তার /carsমধ্যে অন্য আইটেম যুক্ত করা হয়।/oldestdelete


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

4
সুতরাং এই উত্তরের সমস্যাটি (এটি একটি শালীন উত্তর, তবে সম্পূর্ণ নয়) এটি হ'ল তিনি যে জিজ্ঞাসা করেছেন তার মূল প্রশ্নটির দিকে লক্ষ্য রাখে না: আপনি কেন কাস্টম জেএসএন ডেটার চেয়ে HTTP ক্রিয়া এবং ইউআরআই ব্যবহার করবেন (সম্ভবত কিছু প্রকারের হতে পারে) JSON- ভিত্তিক এপিআই অনুরোধ সিনট্যাক্স)। আপনি আপনার কাস্টম জেএসএন সিনট্যাক্সটি তৈরি করতে পারেন যাতে এটি "তাত্ক্ষণিকভাবে ... ডেটার সাথে যা ঘটছে তা উপকরণ"। আপনি যা করতে পারবেন না তা হ'ল এইচটিটিপি-র শীর্ষে বিল্ট-ইন সুবিধাগুলি এবং নেটওয়ার্ক স্তরগুলি ব্যবহার করা আপনি যেমন এমন একটি এপিআই দিয়ে পারেন যা সমস্ত রেস্ট্রিকাল কনভেনশন অনুসরণ করে। অবশ্যই আমার উত্তরটি নিখুঁত নয়;)
মের্লিন মরগান-গ্রাহাম

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

10
মোছার বদলে: / গাড়ি / সবচেয়ে পুরনো, কীভাবে জিইটি: / কার / সবচেয়ে পুরনো একটি ডিলেট মেনে চলবে? এইভাবে, আপনার দুটি পৃথক আদর্শবান্ধব কমান্ড রয়েছে।
নিল

3
+1 টি; আমি সম্মতি জানাই এটি একটি ভাল উত্তর (আমি আবার মজা এবং লাভের জন্য এর বাইরে যাচ্ছি)। POST: /cars/oldestএকটি মোছার জন্য প্রতিস্থাপন হওয়া খুব একটা অর্থবোধ করে না। এর মতো কিছু - POST: /cars/oldest/deleteসম্ভবত, আমার মনে হয় আমি নীলের সমাধান আরও ভাল পছন্দ করি। প্রত্যক্ষ মুছলে মুছে ফেলা তার একমাত্র সুবিধা হ'ল পারমাণবিকতা- আমি এই জাতীয় কিছু বাস্তবায়নের আগে একটি অ-স্বাক্ষরিত দৃশ্যের সাথে একটি পরিষ্কার ব্যবসায়ের ন্যায়সঙ্গততা চাই। আপনাকে সমস্ত অবজেক্ট / ইউআরএলগুলিতে সমস্ত ক্রিয়া সমর্থন করার দরকার নেই।
মের্লিন মরগান-গ্রাহাম

39

এটি একটি সুরক্ষা এবং রক্ষণাবেক্ষণের প্রশ্ন।

নিরাপদ পদ্ধতি

যখনই সম্ভব, সম্ভাব্য দুর্বলতা সীমাবদ্ধ করার জন্য আপনার জিইটি এবং হেডের মতো 'নিরাপদ' (একমুখী) পদ্ধতি ব্যবহার করা উচিত।

আদর্শশক্তি

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

উৎস


1
দুঃখিত, তবে পুট এবং ডিএলটিই আইডিপোটেন্ট পদ্ধতিগুলি কীভাবে রয়েছে? তারা সার্ভারের অবস্থা এবং এর ডেটা প্রভাবিত করে!
মাহমুদ আল-কুদসি

27
@ কম্পিউটার: একই পুট বা একই মুছে ফেলার ফলাফল একই চূড়ান্ত অবস্থায় রয়েছে। "আদর্শবান" এর অর্থ এটিই
Ignacio Vazquez-Abram

4
আরও স্পষ্টতার জন্য: একটি অপারেশন এফ আদর্শবান, যদি এর একক প্রয়োগ এবং এর ফলস্বরূপ বিভিন্ন অ্যাপ্লিকেশন উভয়ই একই ফলাফল দেয়। আরও সুনির্দিষ্টভাবে F হ'ল আদর্শবাদী এবং যদি কেবল F (x) = F (F (x)) থাকে। উদাহরণস্বরূপ, মোছা আদর্শবান, কারণ আপনি যখন কোনও আইটেম একবার মুছে ফেলেন বা বেশ কয়েকবার মুছবেন তখন ফলাফলটি একই: আইটেমটি একবারে মুছে ফেলা হবে প্রথম অ্যাপ্লিকেশনটি দিয়ে এবং মুছলে দ্বিতীয় বা তৃতীয় অ্যাপ্লিকেশনটিতে কিছুই ঘটে না।
কুর্তাল

1
তবে সৃষ্টির ক্ষেত্রে, আপনি যখন একটি কমান্ড কমান্ড দিয়ে একটি নতুন রেকর্ড তৈরি করেন এবং আবার একই আদেশটি প্রদান করেন, তখন দুটি রেকর্ড তৈরি হয় (সম্ভবত) উভয়ই একই তথ্য প্রতিফলিত করে)।
কুর্তাল

কুর্তাল - আইডেম্পোটেন্টের জন্য আপনার কার্যকরী সংজ্ঞাটি 'এফ (এক্স) = এফ (এক্স) এফ (এক্স)' হওয়া উচিত। যদিও এটি উচ্চারণ ভাল।
জেরার্ড ওনিল

26

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


2
এই নিয়ে মাথা ঘুরতে আমি কিছুটা সমস্যায় পড়েছিলাম। এই পোস্টটি ( lornajane.net/posts/2013/… ) যে ক্রিয়াটি HTTP অনুরোধ থেকে আসা উচিত যাতে ইউআরআই কেবল তখন নামগুলি রাখতে পারে এটি আমার পক্ষে একটি
বাচ্চাটি

9

আপনি জিজ্ঞাসা করেছেন :

সাধারণ _P_POST এর মাধ্যমে কেবল JSON অবজেক্ট গ্রহণ করা এবং তারপরে JSON এও সাড়া দেওয়া কি সহজ হবে না?

রিস্টে উইকিপিডিয়া থেকে :

RESTful অ্যাপ্লিকেশনগুলি নির্বাচিত নেটওয়ার্ক প্রোটোকল দ্বারা সরবরাহিত পূর্ব-বিদ্যমান, ভাল-সংজ্ঞায়িত ইন্টারফেস এবং অন্যান্য অন্তর্নির্মিত ক্ষমতাগুলির ব্যবহার সর্বাধিক করে তোলে এবং এর উপরে নতুন অ্যাপ্লিকেশন-নির্দিষ্ট বৈশিষ্ট্যগুলির সংযোজনকে ন্যূনতম করে দেয়

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

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

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

আপনি যে প্রকৃত অবজেক্টের সাথে কাজ করছেন তা যে কোনও বিন্যাসে থাকতে পারে। এই ধারণাটি হ'ল ব্যবহারকারীরা আপনার সেই ক্রিয়াকলাপগুলি উদ্বোধন করতে যতটা সম্ভব HTTP- র পুনরায় ব্যবহার করা উচিত (উত্স, রাজ্য পরিচালনা / রূপান্তর, মুছে ফেলা)।

আপনি জিজ্ঞাসা করেছেন :

আমি কিছু অনুপস্থিত করছি?

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

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


8

ডেটা ধরণের সংজ্ঞা দিতে এক্সটেনশন ব্যবহারের ক্ষেত্রে to আমি লক্ষ্য করেছি যে মেলচিম্প এপিআই এটি করছে, তবে আমি মনে করি এটি ভাল ধারণা নয়।

GET /zzz/cars.json/1

GET /zzz/cars.xml/1

আমার শব্দটি একটি ভাল ধারণার মতো, তবে আমি মনে করি "বয়স্ক" পদ্ধতির আরও ভাল - এইচটিটিপি শিরোনাম ব্যবহার করে

GET /xxx/cars/1
Accept: application/json

এছাড়াও এইচটিটিপি শিরোনাম ক্রস ডেটা টাইপ যোগাযোগের জন্য অনেক ভাল (যদি কখনও কারওর প্রয়োজন হয়)

POST /zzz/cars
Content-Type: application/xml     <--- indicates we sent XML to server
Accept: application/json          <--- indicates we want get data back in JSON format  

4

আমি কিছু অনুপস্থিত করছি?

হ্যাঁ. ;-)

অভিন্ন ইন্টারফেস সীমাবদ্ধতার কারণে এই ঘটনাটি বিদ্যমান । REST চাকাটি পুনরায় উদ্ভাবনের পরিবর্তে ইতিমধ্যে বিদ্যমান মান ব্যবহার করা পছন্দ করে। এইচটিটিপি স্ট্যান্ডার্ডটি ইতিমধ্যে অত্যন্ত স্কেলেবল হিসাবে প্রমাণিত হয়েছে (ওয়েবটি কিছু সময়ের জন্য কাজ করছে)। আমরা কেন এমন কিছু স্থির করব যা ভাঙা হয়নি?!

দ্রষ্টব্য: আপনি পরিষেবা থেকে ক্লায়েন্টদের ডিকুয়াল করতে চাইলে অভিন্ন ইন্টারফেস সীমাবদ্ধতা গুরুত্বপূর্ণ। এটি একে অপরের থেকে ডিক্লুপ করার জন্য ক্লাসগুলির জন্য ইন্টারফেসগুলি সংজ্ঞায়িত করার অনুরূপ। তথ্যের। এখানে অভিন্ন ইন্টারফেস মত মান নিয়ে গঠিত HTTP- র , MIME প্রকারসমূহ , কোনো URI , RDF , লিঙ্ক ডেটা vocabs , Hydra vocab ইত্যাদি ...


2

প্রোগ্রামিংয়ে গুড সেমেন্টিক্স গুরুত্বপূর্ণ।

জিইটি / পোষ্টের পাশাপাশি আরও কয়েকটি পদ্ধতি ব্যবহার করা সহায়ক হবে কারণ এটি আপনার কোডের পঠনযোগ্যতা বৃদ্ধি করবে এবং বজায় রাখা আরও সহজ করে তুলবে।

কেন?

কারণ আপনি জানেন যে জিইটি আপনার এপিআই থেকে ডেটা পুনরুদ্ধার করবে। আপনি জানেন পোষ্ট আপনার সিস্টেমে নতুন ডেটা যুক্ত করবে। আপনি জানেন পুট আপডেট করবে। মোছা সারি ইত্যাদি সরিয়ে ফেলবে ইত্যাদি,

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

আমি পিএইচপি ব্যবহার করি, তাই আমি ফাংশন_অস্তাদীদের ব্যবহার করি (আমার মনে হয় এটি বলা হয়)। যদি ফাংশনটি বিদ্যমান না থাকে তবে আমি একটি 405 নিক্ষেপ করি (পদ্ধতিটি অনুমতি নেই)।


2

বিল ভেনারস: "কেন বিশ্রাম ব্যর্থ হয়েছে" শিরোনামে আপনার ব্লগ পোস্টে আপনি বলেছিলেন যে আমাদের চারটি এইচটিটিপি ক্রিয়া - জিইটি, পোষ্ট, পুট, এবং মুছে ফেলা দরকার — ক্রিয়াপদ? কেন GET এবং পোস্ট যথেষ্ট নয়?

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

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

জিইটি এবং পোস্টের মধ্যে PUT এবং মুছে ফেলা মাঝখানে। পুট বা ডিলিট এবং পোষ্টের মধ্যে পার্থক্যটি হ'ল পুট এবং ডিলেটটি * আদর্শবান, যদিও পোষ্ট হয় না। প্রয়োজনে পুট এবং ডিলিট পুনরাবৃত্তি করা যেতে পারে। ধরা যাক আপনি কোনও সাইটে একটি নতুন পৃষ্ঠা আপলোড করার চেষ্টা করছেন। বলুন আপনি http://www.example.com/foo.html এ একটি নতুন পৃষ্ঠা তৈরি করতে চান, যাতে আপনি আপনার সামগ্রীটি টাইপ করেন এবং আপনি এটি URL এ রেখে দেন। সার্ভারটি সেই URL তৈরি করে যা আপনি সরবরাহ করেন। এখন, ধরুন যে কোনও কারণে আপনার নেটওয়ার্ক সংযোগ হ্রাস পাচ্ছে। আপনি নিশ্চিত নন, অনুরোধটি পেয়ে গেল কি না? নেটওয়ার্কটি ধীর গতির হতে পারে। সম্ভবত একটি প্রক্সি সার্ভার সমস্যা ছিল। সুতরাং এটি আবার চেষ্টা করা পুরোপুরি ঠিক আছে again আপনার পছন্দ অনুসারে। কারণ একই দস্তাবেজটি একই ইউআরএলটিতে দশ বার স্থাপন করা একবারে রাখার চেয়ে আলাদা হবে না। মোছার ক্ষেত্রে একই কথা। আপনি দশবার কিছু মুছে ফেলতে পারেন এবং এটি একবারে মুছে ফেলার মতো।

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

আরও তথ্যের জন্য দয়া করে url দেখুন। http://www.artima.com/lejava/articles/why_put_and_delete.html

হালনাগাদ:

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

নিম্নলিখিত উদাহরণগুলি বিবেচনা করুন:

a = 4;

A ++;

প্রথম উদাহরণটি আদর্শবান: আমরা যতবার এই বিবৃতিটি কার্যকর করি না কেন, এটি সর্বদা 4 হবে The দ্বিতীয় উদাহরণটি আদর্শবান নয়। এটি 10 ​​বার কার্যকর করার ফলে 5 বার দৌড়ানোর মতোই আলাদা ফলাফল হবে। যেহেতু উভয় উদাহরণই ক এর মান পরিবর্তন করছে, উভয়ই নিরাপদ পদ্ধতি।


1
একটি নতুন পৃষ্ঠার উদাহরণ সম্পর্কে, POST ব্যবহার করা উচিত নয়, যখন একটি আপডেটের জন্য পুট? একটি নতুন পৃষ্ঠা তৈরি করা এমন একটি প্রক্রিয়া যা প্রতিবারই নতুন ফলাফলের ঝাঁকুনি দেয়, যখন একই সম্পাদনাটি প্রতিবার একই ফলাফলকে ইয়েল্ডিং করে যে কোনও পরিমাণ পুনঃনির্মাণ করা যেতে পারে। যদিও সুন্দর শব্দবন্ধ এবং ব্যাখ্যা।
স্পাইরিটো

0

মূলত REST হ'ল ( উইকি ):

  1. ক্লায়েন্ট – সার্ভার আর্কিটেকচার
  2. Statelessness
  3. Cacheability
  4. স্তরযুক্ত সিস্টেম
  5. চাহিদা অনুসারে কোড (alচ্ছিক)
  6. ইউনিফর্ম ইন্টারফেস

REST প্রোটোকল নয়, এটি নীতিমালা। বিভিন্ন ইউরিস এবং পদ্ধতি - এমন কাউকে বলা হয় সেরা অনুশীলন।

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