রেস্ট ডিলিট কি আসলেই আদর্শবান?


165

ডিলিটি আদর্শবান হওয়ার কথা।

যদি আমি http://example.com/account/123 মুছে ফেলি তবে এটি অ্যাকাউন্টটি মুছে ফেলবে

আমি যদি আবার এটি করি তবে আমি কী 404 আশা করব, যেহেতু অ্যাকাউন্টটি আর বিদ্যমান নেই? আমি যদি এমন কোনও অ্যাকাউন্ট মুছে ফেলার চেষ্টা করি যা কখনই অস্তিত্বহীন?


11
উত্তরগুলি ছাড়াও, আমি সাধারণভাবে আদর্শগত বৈশিষ্ট্যটির প্রতি খুব বেশি মনোযোগ না দেওয়ার পরামর্শ দিই: এটি চলাচল এবং সামনের অনুরোধগুলির বিষয়ে কিছু বলে না। উদাহরণস্বরূপ একই "আর 1" পিট অনুরোধের এন + 1 এর একই প্রভাব থাকতে হবে, তবে আপনি জানেন না যে অন্য ক্লায়েন্টটি আপনার মধ্যে একটি আলাদা PUT / DELETE "R2" অনুরোধ করেছে, তাই এন আর 1 = আর 1 এবং এম আর 2 = আর 2, এমন কোনও কিছু যেখানে আপনি ইন্টারলিভড "আর 1" এবং "আর 2" অনুরোধগুলি প্রয়োজনীয়ভাবে "চেহারা" হবে না যদি আপনি কেবলমাত্র একটি ক্লায়েন্টের দৃষ্টিভঙ্গি গ্রহণ করেন।
ব্রুনো

উত্তর:


188

অনুরোধটি সম্পূর্ণ হওয়ার পরে আইডেম্পোটেন্স সিস্টেমের অবস্থা বোঝায়


সমস্ত ক্ষেত্রে (ত্রুটি সম্পর্কিত সমস্যাগুলি বাদে - নীচে দেখুন), অ্যাকাউন্টটি আর বিদ্যমান নেই।

থেকে এখানে

"পদ্ধতিতে" আইডেম্পোটেন্স "এর সম্পত্তিও থাকতে পারে ( ত্রুটি বা মেয়াদোত্তীর্ণ সমস্যাগুলি বাদ দিয়ে ) N> 0 অভিন্ন অনুরোধের পার্শ্ব প্রতিক্রিয়াগুলি একটি অনুরোধের অনুরূপ The পদ্ধতিগুলি জেট, হেড, পুট এবং ডিলেট ভাগ করে দেয় এই সম্পত্তিটি। এছাড়াও, বিকল্পগুলি এবং ট্র্যাকের পদ্ধতিগুলির কোনও পার্শ্ব প্রতিক্রিয়া থাকতে হবে না এবং তাই সহজাতভাবে আদর্শবান হয় ""


N> 0 অভিন্ন অনুরোধগুলির পার্শ্ব প্রতিক্রিয়াগুলি কী কী তা একক অনুরোধের মতোই।

আপনি স্থিতি কোডটি আলাদা হবে এমনটি আশা করা ঠিক হবে তবে এটি আদর্শের মূল ধারণাটিকে প্রভাবিত করে না - আপনি সার্ভারের স্থিতিতে অতিরিক্ত পরিবর্তন ছাড়াই একবারে অনুরোধটি পাঠাতে পারেন।


3
পার্শ্ব-প্রতিক্রিয়া! == সার্ভারের অবস্থা
ডাব্লুআরপিআরএল

2
@wprl এই "পার্শ্ব-প্রতিক্রিয়া" আসলে কী তা নিয়ে বিতর্ক রয়েছে। এটি "সার্ভারের অবস্থা" হতে পারে বা এটি ক্লায়েন্টকে পাঠানো প্রতিক্রিয়া হতে পারে। leedavis81.github.io/is-a-http-delete-requests-idempotent
আলিরেজা

এখানে একটি যুক্তি রয়েছে যে 4040 সেকেন্ড ডিলিটে আসলে সার্ভারের অবস্থার পরিবর্তন করতে পারে: stackoverflow.com/a/45194747/317522
পাওলো মেরসন

1
@ পাওলোমারসন ধন্যবাদ, ব্যক্তিগতভাবে আমি মনে করি না যে এটি দ্বিতীয় রিটার্নটি 404 বা 200 হয় কিনা, সার্ভারের অবস্থার কোনও পরিবর্তন হয়নি তাই আমি এতে সন্তুষ্ট।
ক্রিস ম্যাককলি

46

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

http://www.w3.org/Potocols/rfc2616/rfc2616-sec9.html#sec9.1.2 বলেছেন:

পদ্ধতিতে "আইডেম্পোটেন্স" এর সম্পত্তিও থাকতে পারে (ত্রুটি বা মেয়াদোত্তীর্ণ সমস্যাগুলি বাদ দিয়ে) এন> 0 অভিন্ন অনুরোধগুলির পার্শ্ব প্রতিক্রিয়াগুলি একক অনুরোধের মতোই।

আপনি কোনও ভিন্ন প্রতিক্রিয়া কোড পেতে পারেন, একই উত্সে N + 1 ডিলেট অনুরোধগুলি প্রেরণের প্রভাবটিকে একই হিসাবে বিবেচনা করা যেতে পারে।


13

গুরুত্বপূর্ণ পার্থক্য হ'ল আদর্শশক্তি পার্শ্ব-প্রতিক্রিয়াগুলিকে বোঝায় , সমস্ত -প্রভাব বা প্রতিক্রিয়া নয়। আপনি যদি কিছু করেন DELETE http://example.com/account/123তবে প্রভাবটি হল যে অ্যাকাউন্টটি এখন 123 সার্ভার থেকে মুছে ফেলা হয়েছে। এটি হ'ল একমাত্র এবং একমাত্র প্রভাব, একমাত্র এবং কেবলমাত্র সার্ভারের অবস্থাতে পরিবর্তন । এখন আপনাকে DELETE http://example.com/account/123আবার একই অনুরোধটি করতে বলুন, সার্ভারটি ভিন্নভাবে প্রতিক্রিয়া জানাবে, তবে এর অবস্থা একই is

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


7

থেকে HTTP- র জন্য RFC :

পদ্ধতিতে "আইডেম্পোটেন্স" এর সম্পত্তিও থাকতে পারে (ত্রুটি বা মেয়াদোত্তীর্ণ সমস্যাগুলি বাদ দিয়ে) এন> 0 অভিন্ন অনুরোধগুলির পার্শ্ব প্রতিক্রিয়াগুলি একক অনুরোধের মতোই।

এটি "প্রতিক্রিয়া" নয়, "পার্শ্ব প্রতিক্রিয়া" নোট করুন।


7

হ্যাঁ. প্রতিক্রিয়া কোড নির্বিশেষে।

HTTP 1.1 (জোর খনি) এর জন্য সর্বশেষতম আরএফসি থেকে :

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

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

গণনা আদর্শিকতা একটি সিস্টেমের দৃ ust়তা সম্পর্কে। যেহেতু জিনিসগুলি ব্যর্থ হতে পারে (যেমন নেটওয়ার্ক আউটেজ), যখন কোনও ব্যর্থতা সনাক্ত হয়, আপনি কীভাবে পুনরুদ্ধার করবেন? সবচেয়ে সহজ পুনরুদ্ধার হ'ল এটি আবার করা, তবে এটি কেবল তখনই কাজ করে যদি এটি আবার করা আদর্শবান হয়। যেমন discard(x)আদর্শবান, তবে pop()তা নয়। এটি সবই ত্রুটি পুনরুদ্ধারের বিষয়ে।


2

আমার মনে হয় একই জিনিস, 404 - অ্যাকাউন্টের অস্তিত্ব নেই।

আপনার পক্ষে 400 টি বিতর্ক হতে পারে - খারাপ অনুরোধ। তবে বিশ্রামের অর্থে আপনি যে ক্রিয়াটি সম্পাদন করার জন্য অনুরোধ করেছেন সেই বস্তুর অস্তিত্ব নেই। এটি 404 এ অনুবাদ হয়।


1
400 জেনারেট করার জন্য আপনাকে জানতে হবে যে অবজেক্টটি বিদ্যমান ছিল যা খুব অস্থির।
অন্নাকাটা

1
@ ননাকাটা, ৪০০ এমনকি এমন সংস্থানগুলির জন্যও নয় যা সম্ভবত বিদ্যমান ছিল (সম্ভবত আপনার 410 / মনে আছে) এটি খারাপ অনুরোধগুলির জন্য "অনুরোধটি ভ্রষ্ট সিনট্যাক্সের কারণে সার্ভারের দ্বারা বোঝা যায়নি।"
ব্রুনো

3
@ ব্রুনো - এর অর্থ কী তা সম্পর্কে আমি সচেতন, ওপি এটির উদ্ধৃতি দিয়েছিল।
অন্নাকাটা

1
আমার মনে হয় 200 ভাল হবে। আপনি সার্ভারের অবস্থাটি চান যে অ্যাকাউন্টটি চলে গেছে। আসলে কোন অনুরোধটি এটিকে দূরে সরিয়ে এনেছে তাতে কী আসে যায়? এটি এখনও দ্বিতীয় অনুরোধে চলে গেছে, সার্ভারের স্থিতি পরিবর্তন হয়নি।
অ্যান্ডি

1

আমার অন্য উত্তর থেকে উদ্ধৃত এখানে :

Icallyতিহাসিকভাবে, 1999-এ প্রকাশিত আরএফসি 2616 হ'ল সবচেয়ে রেফারেন্সড এইচটিটিপি 1.1 স্পেস। দুর্ভাগ্যক্রমে আইডেম্পোটেন্সি সম্পর্কিত এটির বিবরণ অস্পষ্ট ছিল , যা এই সমস্ত বিতর্কের জায়গা ছেড়ে দেয়। কিন্তু যে চশমা বোঝায় যা RFC 7231. দ্বারা বাতিল করা হয়েছে থেকে উদ্ধৃত জন্য RFC 7231, বিভাগ 4.2.2 Idempotent পদ্ধতি , জোর খনি:

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

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


ঠিক আছে তাই আদর্শের সম্পর্কে নয়। তবে তারপরে একটি ফলো-আপ প্রশ্ন হতে পারে, আমরা যদি এখনও পরবর্তী মুছে ফেলাতে 204 ব্যবহার করা বেছে নিই? ঠিক আছে?

ভাল প্রশ্ন. অনুপ্রেরণা বোধগম্য: ক্লায়েন্টটিকে ত্রুটি পরিচালনার বিষয়ে চিন্তা না করেই এখনও তার উদ্দেশ্যপ্রাপ্ত ফলাফলটিতে পৌঁছানোর অনুমতি দেওয়া। আমি বলব, পরবর্তী মুছে ফেলাতে 204 ফিরিয়ে দেওয়া, মূলত ক্ষতিকারক একটি সার্ভার-সাইড "হোয়াইট মিথ্যা", যা ক্লায়েন্ট-পক্ষ অবিলম্বে কোনও পার্থক্য জানায় না won't এই কারণেই বন্য অঞ্চলে লোকেরা তা করছে এবং এটি এখনও কার্যকর। শুধু মনে রাখবেন যে, এই জাতীয় মিথ্যা শব্দার্থগতভাবে অদ্ভুত হিসাবে বিবেচিত হতে পারে, কারণ "জিইটি / অস্তিত্ব" 404 ফেরত দেয় তবে "মুছে ফেলা / অস্তিত্ব" 204 দেয়, তখন ক্লায়েন্টটি বুঝতে পারে যে আপনার পরিষেবা সম্পূর্ণরূপে মেনে চলে না বিভাগ 6.5.4 404 পাওয়া যায় নি

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

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