এইচটিটিপি মুছে ফেলার অনুরোধের জন্য কি কোনও সত্তা সংস্থা অনুমোদিত?

717

কোনও HTTP মোছার অনুরোধ জারি করার সময়, অনুরোধটি ইউআরআই মুছে ফেলার জন্য সম্পদটি সম্পূর্ণরূপে সনাক্ত করা উচিত। তবে, অনুরোধের সত্তার অংশ হিসাবে অতিরিক্ত মেটা-ডেটা যুক্ত করার অনুমতি রয়েছে কি?

http  rest 
— Haacked
সূত্র
4
এএসপি.নেট ওয়েবএপিআই 2 এচডিপিডিলেট এন্ডপয়েন্টস পয়েন্টের জন্য বডি প্যারামিটার উপেক্ষা করা হয়।
— জেনি ও'রেইলি
2
আমারও তেমন উদ্বেগ রয়েছে তবে আমার মামলাটি আলাদা। আমি যখন একশটি বস্তু মুছতে চাই তখন আমি একটি ব্যাচ মুছার অনুরোধ জানাতে চাই। অবশ্যই এটি প্রাক HTTP 2.0 নেটওয়ার্কগুলির জন্য দুর্দান্ত পারফরম্যান্সের উত্সাহ।
— সিঙ্গাগর্ল
1
এইচটিটিপি / ২ এ কি কোনও পরিবর্তন হয়েছে?
— জ্যোতমন সিং

উত্তর:

570

অনুমানটি স্পষ্টভাবে এটি নিষিদ্ধ বা নিরুৎসাহিত করে না, তাই আমি এটির অনুমোদিত বলে বলব।

মাইক্রোসফ্ট এটিকে একইভাবে দেখেছে (আমি শ্রোতাদের মধ্যে বচসা শুনতে পাচ্ছি), তারা এমএসডিএন নিবন্ধে অ্যাডো.নেট ডেটা সার্ভিসেস ফ্রেমওয়ার্কের মোছার পদ্ধতিটি সম্পর্কে বলেছেন :

যদি একটি মোছার অনুরোধে কোনও সত্তা সংস্থা অন্তর্ভুক্ত থাকে, তবে শরীরটি উপেক্ষা করা হবে [...]

অতিরিক্তভাবে এখানে অনুরোধের বিষয়ে আরএফসি 2616 (HTTP 1.1) এর যা বলতে হবে তা এখানে রয়েছে :

  • কোনও সত্তা-দেহ কেবল তখনই উপস্থিত থাকে যখন কোনও বার্তা-দেহ উপস্থিত থাকে (বিভাগ 7.2)
  • একটি বার্তা-শরীরে উপস্থিতি একটি Content-Lengthবা Transfer-Encodingশিরোলেখের অন্তর্ভুক্তি দ্বারা সংকেতযুক্ত (বিভাগ 4.3)
  • যখন অনুরোধ পদ্ধতির স্পেসিফিকেশন কোনও সত্তা-দেহ প্রেরণের অনুমতি দেয় না তখন কোনও বার্তা-বডি অন্তর্ভুক্ত করা উচিত নয় (বিভাগ 4.3)
  • কোনও সত্তা-দেহ কেবলমাত্র ট্র্যাক অনুরোধগুলিতে স্পষ্টভাবে নিষিদ্ধ, অন্য সমস্ত অনুরোধের ধরনগুলি সীমিত নয় (বিভাগ 9, এবং 9.8 বিশেষত)

প্রতিক্রিয়াগুলির জন্য, এটি সংজ্ঞায়িত করা হয়েছে:

  • কোনও বার্তা-বডি অন্তর্ভুক্ত করা হয়েছে কিনা তা অনুরোধের পদ্ধতি এবং প্রতিক্রিয়া স্থিতির উভয়ের উপর নির্ভর করে (বিভাগ 4.3)
  • হেড অনুরোধের প্রতিক্রিয়াগুলিতে একটি বার্তা-দেহ স্পষ্টভাবে নিষিদ্ধ করা হয়েছে (বিভাগ 9, এবং 9.4 বিশেষভাবে)
  • একটি বার্তা-বডি স্পষ্টভাবে 1xx (তথ্যগত), 204 (কোনও সামগ্রী নেই), এবং 304 (সংশোধিত নয়) প্রতিক্রিয়াগুলিতে স্পষ্টভাবে নিষিদ্ধ করা হয়েছে (বিভাগ 4.3)
  • অন্যান্য সমস্ত প্রতিক্রিয়াগুলির মধ্যে একটি বার্তা-বডি অন্তর্ভুক্ত রয়েছে যদিও এটি শূন্য দৈর্ঘ্যের হতে পারে (বিভাগ ৪.৩)
— Tomalak
সূত্র
7
@ জেসন অবশ্যই আপনি অতিরিক্ত ডেটা পাস করার জন্য কাস্টম শিরোলেখ ব্যবহার করতে পারেন, তবে কেন অনুরোধের বডিটি ব্যবহার করবেন না।
— তোমালাক
86
যদিও অনুমানটি মেসেজ-বডি রাখার জন্য অনুরোধ মুছে ফেলতে নিষেধ করে না, বিভাগ ৪.৩ ইঙ্গিত দেয় যে দেহটি সার্ভারদের দ্বারা উপেক্ষা করা উচিত যেহেতু ডিলেট সত্তা-দেহগুলির জন্য কোনও "সংজ্ঞায়িত শব্দার্থবিজ্ঞান" নেই : "একটি সার্ভার একটি পড়তে এবং ফরোয়ার্ড করা উচিত কোনও অনুরোধে বার্তা-বডি; অনুরোধের পদ্ধতিতে যদি কোনও সত্তা-দেহের জন্য সংজ্ঞায়িত শব্দার্থকে অন্তর্ভুক্ত না করা হয়, তবে অনুরোধটি পরিচালনা করার সময় বার্তা-বডিটি উপেক্ষা করা উচিত । "
— শেললে
72
দয়া করে নোট করুন যে প্রচুর ক্লায়েন্ট কোনও বডি সহ একটি ডিলেটও পাঠাতে অক্ষম। এটি আমাকে অ্যান্ড্রয়েডে সবেমাত্র জ্বালিয়ে দিয়েছে।
— কার্মিক কোডার
1
@ কার্মিক কোডার: দুর্দান্ত পয়েন্ট। আরও তথ্য: অ্যান্ড্রয়েডে HTTP মোছার অনুরোধ পাঠানো হচ্ছে ।
— এমএস দৌস্তি
2
এইচটিটিপি অনুমানের সাথে মিশে বাস্তবায়ন সম্পর্কে প্রচুর আলোচনা। ক্লায়েন্টরা সেই উপাখ্যানটির ব্যাখ্যা করার উপায়ে জিনিসগুলি বাস্তবায়ন করবে, অনুমানের অর্থের সাথে এটি বিভ্রান্ত করবেন না। আসল ঘটনাটি এই অস্পষ্টটিকে ছেড়ে দেয়। আমি ব্যাখ্যার সাথে একমত নই কারণ সত্তা-দেহের পক্ষে কোনও নির্ধারিত শব্দার্থবিজ্ঞান নেই যে এমন কোনও ইমপ্লেস আছে যে এটি উপেক্ষা করা উচিত। আমি মনে করি লোকেরা ক্লায়েন্টদের সুনির্দিষ্ট ব্যাখ্যাগুলির পিছনে পিছনে কাজ করছে যা বিদ্যমান (জার্সি, অ্যান্ড্রয়েড টেস্ট ক্লায়েন্টস ইত্যাদি) এবং অনুমানের সত্য হওয়ার চেয়ে ব্যাখ্যাকে ন্যায়সঙ্গত করার চেষ্টা করছে। মানুষ হতাশ হয়।
— জিব্রোন
169

HTTP 1.1 স্পেসিফিকেশন ( আরএফসি 7231 ) এর সর্বশেষ আপডেটটি মুছে ফেলার অনুরোধে একটি সত্তা সংস্থাটিকে স্পষ্টভাবে অনুমতি দেয়:

একটি মোছার অনুরোধ বার্তার মধ্যে একটি পেডের কোনও নির্ধারিত শব্দার্থবিজ্ঞান নেই; একটি মোছার অনুরোধে পে-লোড বডি প্রেরণের ফলে কিছু বিদ্যমান বাস্তবায়ন অনুরোধটিকে প্রত্যাখ্যান করতে পারে।

— grzes
সূত্র
3
স্পেকের সর্বশেষ অ-অনুমোদিত সংস্করণটি এই প্রয়োজনীয়তাটি সরিয়ে দেয়। সর্বশেষ অনুমোদিত অনুমোদিত সংস্করণটি এখনও উপরে বর্ণিত আরএফসি 2616।
— বিশপজেড
4
কোন সংস্করণ? সংস্করণ ২০ টি এখনও সংস্করণ ১৯-এর মতো একই শব্দের সাথে রয়েছে যা আমি উপরে লিঙ্ক করেছি: "মোছার অনুরোধে দেহগুলির কোনও সংজ্ঞায়িত শব্দার্থবিজ্ঞান নেই Note মনে রাখবেন যে একটি মোছার অনুরোধের ভিত্তিতে একটি দেহ পাঠানো অনুরোধটিকে প্রত্যাখাত করার জন্য কিছু বিদ্যমান বাস্তবায়ন ঘটাতে পারে" "
— গ্রিজ
11
সংস্করণ ২ suggestions টি পরামর্শ যা আপনি কোনও দেহের অনুমতি দিতে পারেন: A payload within a DELETE request message has no defined semantics; sending a payload body on a DELETE request might cause some existing implementations to reject the request.সুতরাং এটি একটি পশ্চাদপটে সামঞ্জস্যতার সতর্কতা সহ আসে, এটি পরামর্শ দিচ্ছে যে পরবর্তী মানটি বলবে: 'হ্যাঁ! DELETEএকটি শরীর থাকতে পারে `
— বিশুদ্ধ.ক্রোম
4
আরএফসি 7231 বিভাগ 4.3.5 সংস্করণ 26 সহ ভাষা চূড়ান্ত করেছে A payload within a DELETE request message has no defined semantics। সুতরাং শরীর অনুমতি দেওয়া হয়।
— mndrix
6
বডি অনুমোদিত তবে অনুরোধের সাথে প্রাসঙ্গিক হওয়া উচিত নয়। এটি ব্যবহার করার একেবারেই কোনও লাভ নেই।
— এভার্ট
54

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

— evan.leonard
সূত্র
2
গুগল অ্যাপ ইঞ্জিন অনুরোধ সংস্থার পরিবর্তে একটি খালি ডিফল্ট সত্তা ইনস্ট্যান্ট করে এবং পাস করে।
— অলিভার হাউসলার
— এমএস দৌস্তি
50

মুছে ফেলার অনুরোধে দেহটি ব্যবহার করার একটি কারণ হ'ল আশাবাদী সম্মতি নিয়ন্ত্রণ for

আপনি একটি রেকর্ডের সংস্করণ 1 পড়েন।

GET /some-resource/1
200 OK { id:1, status:"unimportant", version:1 }

আপনার সহকর্মী রেকর্ডের সংস্করণ 1 পড়েন।

GET /some-resource/1
200 OK { id:1, status:"unimportant", version:1 }

আপনার সহকর্মী রেকর্ড পরিবর্তন করে এবং ডাটাবেস আপডেট করে, যা সংস্করণটি 2 তে আপডেট করে:

PUT /some-resource/1 { id:1, status:"important", version:1 }
200 OK { id:1, status:"important", version:2 }

আপনি রেকর্ডটি মুছতে চেষ্টা করুন:

DELETE /some-resource/1 { id:1, version:1 }
409 Conflict

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

এটির ব্যবহারের আর একটি কারণ হ'ল একাধিক রেকর্ডগুলি মুছে ফেলা (উদাহরণস্বরূপ, সারি-নির্বাচন চেক-বাক্স সহ একটি গ্রিড)।

DELETE /messages
[{id:1, version:2},
{id:99, version:3}]
204 No Content

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

এটি টমক্যাট (7.0.52) এবং স্প্রিং এমভিসি (4.05) এ কাজ করে, সম্ভবত সম্ভবত পূর্ববর্তী সংস্করণগুলিও:

@RestController
public class TestController {

    @RequestMapping(value="/echo-delete", method = RequestMethod.DELETE)
    SomeBean echoDelete(@RequestBody SomeBean someBean) {
        return someBean;
    }
}
— নীল ম্যাকগুইগান
সূত্র
15
জিইটি (এবং মুছে ফেলুন) এ মৃতদেহ পাওয়া পরিষ্কারভাবে HTTP এবং REST এর সাথে খারাপ ব্যবহার করছে। সম্মতি নিয়ন্ত্রণের সাথে কাজ করার জন্য অন্যান্য পদ্ধতি রয়েছে (উদাঃ যদি-সংশোধিত-যেহেতু এবং এ্যাট্যাগগুলি)।
— ব্রুনো
19
যখন স্পেকটি শরীরকে মুছে ফেলতে নিষেধ করে না তখন কীভাবে এটি পরিষ্কারভাবে এটির সাথে খারাপ ব্যবহার করা হচ্ছে?
— নিল ম্যাকগুইগান
5
কারণ আপনি দেহ নিয়ে কিছু করার কথা নয়। দেখুন: স্ট্যাকওভারফ্লো.com
— ব্রুনো
14
এটি ঠিক একই সমস্যা: জিইটি আপনাকে ইউআরআই দ্বারা চিহ্নিত সংস্থার প্রতিনিধিত্ব পুনরুদ্ধার করতে দেয় এবং ইউআরআই দ্বারা চিহ্নিত সংস্থানটি মুছে দেয়। আপনি যদি সুনির্দিষ্ট সংস্করণগুলি মুছতে চান তবে অন্যান্য সংস্করণের জন্য আলাদা ইউআরআই ব্যবহার করুন। ইউআরআই হ'ল এইচটিটিপি / আরএসটি-তে থাকা সংস্থার একমাত্র সনাক্তকারী হওয়া উচিত। যদি আপনার হ্যান্ডেল সামঞ্জস্যের প্রয়োজন হয় তবে শিরোনামগুলিতে মেটাডেটা ব্যবহার করুন (উদাহরণস্বরূপ If-Unmodified-Sinceবা Etag, এটি তাদের জন্য)।
— ব্রুনো
5
কোনও শরীরে কোনও সংস্করণ ক্ষেত্রের পরিবর্তে ইটাগ শিরোলেখ ব্যবহার করুন
— ম্যালহাল
26

আমার কাছে মনে হচ্ছে আরএফসি 2616 এটি নির্দিষ্ট করে না।

বিভাগ ৪.৩ থেকে:

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

এবং বিভাগ 9.7:

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

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

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

সুতরাং এটি স্পষ্টভাবে অনুমোদিত বা অস্বীকৃত নয় এবং পথের একটি প্রক্সি বার্তার মূল অংশটি সরিয়ে ফেলতে পারে (যদিও এটি এটি পড়তে এবং ফরোয়ার্ড করা উচিত)।

— অ্যাডাম রোজেনফিল্ড
সূত্র
19

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

— বেন ফ্রাইড
সূত্র
1
for whatever reason- কারণ
— অনুমানটি
20
অনুমানটি "তাই বলে না" এটি কেবলমাত্র বলে যে শরীরটি নির্দিষ্টভাবে সংজ্ঞায়িত করা হয় না। যদি এটি সংজ্ঞায়িত না হয় এবং আপনি এটিকে উপেক্ষা করতে চান, শীতল ... এগিয়ে যান এবং এড়িয়ে যান। তবে সরাসরি অনুরোধ প্রত্যাখ্যান করা চরম এবং অপ্রয়োজনীয় বলে মনে হচ্ছে।
— বেন ফ্রাইড
1
অপরিবর্তিত আচরণের উপর নির্ভর করবেন না। এটি একটি দুর্দান্ত সাধারণ অনুশীলন।
— এভার্ট
@ ইতিপূর্বে অপরিবর্তিত আচরণ রয়েছে (যেমন আপনি উদাহরণস্বরূপ সি ভাষার স্পেসিফিকেশনগুলিতে বর্ণনা দেখতে পান) এবং এমন আচরণ রয়েছে যা অনুমোদিত তবে কেবল বর্ণিত হয়নি। অভ্যন্তরীণভাবে একটি বার্তা ব্যবহার করা DELETEহ'ল পরে।
— Alnitak
9

এটি লক্ষণীয় যে, সংস্করণ 3.0 এর জন্য ওপেনপিআই স্পেসিফিকেশন একটি বডি সহ ডিলেট ডিলেট পদ্ধতিগুলির জন্য সমর্থন বাদ দিয়েছে:

রেফারেন্সের জন্য এখানে এবং এখানে দেখুন

এটি ভবিষ্যতে আপনার বাস্তবায়ন, ডকুমেন্টেশন বা এই এপিআইগুলির ব্যবহারকে প্রভাবিত করতে পারে।

— CleverPatrick
সূত্র
7

দেখে মনে হচ্ছে ইলাস্টিক অনুসন্ধান এটি ব্যবহার করে: https://www.elastic.co/guide/en/elasticsearch/references/5.x/search-request-scrol.html#_clear_scrol_api

যার অর্থ নেটটি এটি সমর্থন করে।

মতামত উল্লিখিত মত এটি আর হতে পারে না

— সেবাস্তিয়ান লরবার
সূত্র
1
আপনি যদি অ্যাপাচি HTTP ক্লায়েন্ট ব্যবহার করেন তবে আপনি সহজেই HTTPEntityEnclosingRequestBase প্রসারিত করে এবং getMethod () পদ্ধতিটি ফেরত GET বা DELETE তৈরি করে GET এবং DELETE এর নিজস্ব সংস্করণ তৈরি করতে পারেন। আমরা ইলাস্টিকের সাথে কথা বলার জন্য এটি ব্যবহার করি।
— জিলিস ভ্যান গর্প
2
মৃত লিঙ্ক - দুর্দান্ত। আমাদের সেই লিঙ্কের উত্তরগুলির আরও বেশি প্রয়োজন - না
— কটটন
3
লিঙ্কযুক্ত ডকুমেন্টেশনে এখন কেবলমাত্র POST অনুরোধ রয়েছে, কোনও মোছা নেই। এই উত্তরে একটি নোট যোগ করার উপযুক্ত হতে পারে?
— শুক্রবার
ইলাস্টিকসার্চ জিইটি অনুরোধের সাথে বডি ব্যবহার করে।
— নীধিন ডেভিড
7

এইচটিটিপি মেলিং তালিকায় রয় ফিল্ডিং স্পষ্ট করে যে HTTP মেলিং তালিকায় https://lists.w3.org/ আর্কাইভস / প্রজাতন্ত্র / হিট্প-http-wg/2020 জনমারে/0123.html এবং বলেছেন:

GET / DELETE বডিটি অনুরোধের প্রক্রিয়াজাতকরণ বা ব্যাখ্যার উপর যে কোনও প্রভাব ফেলতে একেবারেই নিষিদ্ধ

এর অর্থ এই যে শরীরটি অবশ্যই সার্ভারের আচরণটি পরিবর্তন করবে না। তারপরে তিনি যুক্ত করেছেন:

বার্তাটি ফ্রেমিং বজায় রাখার জন্য প্রাপ্ত বাইটগুলি পড়ার এবং ফেলে দেওয়ার প্রয়োজনীয়তা বাদ করুন।

এবং অবশেষে শরীরকে নিষেধ না করার কারণ:

আমরা দেহ প্রেরণ নিষিদ্ধ করার একমাত্র কারণ হ'ল এটি অনুমান করে যে কোনও দেহ প্রেরণ করা হবে না তা অলস বাস্তবায়নের দিকে পরিচালিত করবে।

সুতরাং যখন ক্লায়েন্টরা পে-লোড বডিটি প্রেরণ করতে পারে, সার্ভারগুলি এটিকে ফেলে দেওয়া উচিত এবং API গুলি সেই অনুরোধগুলিতে পে-লোড বডিটির জন্য কোনও অর্থ বোঝাতে পারে না।

— রবার্তো পোলি
সূত্র
5

এটি সংজ্ঞায়িত করা হয় না ।

একটি মোছার অনুরোধ বার্তার মধ্যে একটি পেডের কোনও নির্ধারিত শব্দার্থবিজ্ঞান নেই; একটি মোছার অনুরোধে পে-লোড বডি প্রেরণের ফলে কিছু বিদ্যমান বাস্তবায়ন অনুরোধটিকে প্রত্যাখ্যান করতে পারে।
https://tools.ietf.org/html/rfc7231#page-29

— সাইমন জিন
সূত্র
— mndrix
3
এই সঠিক উদ্ধৃতিটি ইতিমধ্যে পূর্ববর্তী উত্তরে অন্তর্ভুক্ত ছিল, এই উত্তরটি মুছে ফেলা উচিত।
— ম্যাডব্রেকস
5

কোনও দেহের সাথে মুছে ফেলা ঝুঁকিপূর্ণ ... আমি REST- র উপরে তালিকা অপারেশনের জন্য এই পদ্ধতির পছন্দ করি:

নিয়মিত অপারেশন

GET / অবজেক্টস / সমস্ত অবজেক্টস পান

GET / অবজেক্ট / আইডি নির্দিষ্ট আইডির সাথে একটি অবজেক্ট পায়

পোস্ট / অবজেক্টস একটি নতুন অবজেক্ট যুক্ত করে

পুট / অবজেক্ট / আইডি নির্দিষ্ট আইডি সহ একটি অবজেক্ট যুক্ত করে, একটি অবজেক্ট আপডেট করে

মোছা / অবজেক্ট / আইডি নির্দিষ্ট আইডি সহ অবজেক্টটিকে মুছে দেয়

সমস্ত কাস্টম ক্রিয়া পোস্ট করা হয়

পোস্ট / অবজেক্টস / অ্যাডলিস্ট শরীরের অন্তর্ভুক্ত অবজেক্টগুলির একটি তালিকা বা অ্যারে যুক্ত করে

পোস্ট / অবজেক্টস / ডিলিটলিস্ট শরীরের অন্তর্ভুক্ত অবজেক্টগুলির একটি তালিকা মুছে দেয়

পোস্ট / অবজেক্টস / কাস্টমকিউয়ারি শরীরে কাস্টম ক্যোয়ারির উপর ভিত্তি করে একটি তালিকা তৈরি করে

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

— এলিজার গারজা
সূত্র
POSTনতুন রিসোর্স তৈরির জন্য একটি ব্যবহার করা ভাল রেস্টস্টি উপায় নয় কারণ পোস্ট পোস্টের প্রতিক্রিয়াগুলির শব্দার্থকতা অস্পষ্ট, বিশেষত লোকেশন শিরোনামের প্রসঙ্গে। আপনি মূলত এইচটিটিপিকে পিছনে রেখে আরপিসিকে উপরে রেখে দিচ্ছেন। সঠিক "এইচটিটিপি / আরএসটি উপায়" হ'ল ডাব্লু PUT/ If-None-Match: *হেডার ব্যবহার করে সংস্থান তৈরি করা (বা সঠিক HTTP পদ্ধতি নির্দিষ্ট করা, MKCOLইত্যাদি দেখুন)।
— এইচএন
4

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

আরএফসি 7231 এর এই অনুচ্ছেদটি কয়েকবার উদ্ধৃত হয়েছে, যা এটির যোগফল করে।

একটি মোছার অনুরোধ বার্তার মধ্যে একটি পেডের কোনও নির্ধারিত শব্দার্থবিজ্ঞান নেই; একটি মোছার অনুরোধে পে-লোড বডি প্রেরণের ফলে কিছু বিদ্যমান বাস্তবায়ন অনুরোধটিকে প্রত্যাখ্যান করতে পারে।

অন্যান্য উত্তরগুলি থেকে আমি যা হারিয়েছি তা হ'ল অন্তর্ভুক্ত। হ্যাঁ DELETEঅনুরোধের ভিত্তিতে এটি একটি বডি অন্তর্ভুক্ত করার অনুমতি দেওয়া হয়েছে তবে এটি শব্দার্থগতভাবে অর্থহীন। এর সত্যিকারের অর্থ হ'ল DELETEএকটি অনুরোধ সংস্থার সাথে একটি অনুরোধ জারি করা শব্দার্থগতভাবে অনুরোধের বডি অন্তর্ভুক্ত না করার সমতুল্য।

একটি অনুরোধ বডি সহ অন্তর্ভুক্তির অনুরোধটিতে কোনও প্রভাব ফেলতে হবে না, তাই এটি অন্তর্ভুক্ত করার কোনও কারণ নেই।

tl; dr: প্রযুক্তিগতভাবে DELETEএকটি অনুরোধ বডি সহ একটি অনুরোধ অনুমোদিত, তবে এটি কখনও কার্যকর হয় না।

— Evert
সূত্র
2
"শব্দার্থগত অর্থহীন" এর অর্থ "এর কোনও সংজ্ঞায়িত শব্দার্থবিজ্ঞান নেই" এর অর্থ একই নয়। পূর্বের অর্থ এটির কোনও অর্থ হতে পারে না । আধুনিকতার সহজ অর্থ হ'ল আরএফসি নিজে specify শব্দার্থকগুলি কী হতে পারে তা নির্দিষ্ট করে না। (আমি আরএফসি লিখি)
— অ্যালনিটাক
1
অন্য কথায়, যদি কোনও এপিআই এর বাস্তবায়নকারী নিজের জন্য কিছু শব্দার্থবিজ্ঞান সংজ্ঞায়িত করতে চায় তবে তারা এগুলি করতে পুরোপুরি মুক্ত।
— Alnitak
1
@ অ্যালনিটাক এটি অবশ্যই একটি ভুল ব্যাখ্যা। সেই সংজ্ঞা অনুসারে যে কোনও HTTP রিকোয়েস্ট বডির কোনও সংজ্ঞায়িত শব্দার্থবিজ্ঞান নেই, তবে DELETE এবং GET কে নির্দিষ্ট করে নির্দিষ্টকরণে ডাকা হয়। GET অনুরোধ সম্পর্কে বিশেষভাবে এ সম্পর্কে কথা বলার মতো এখনও প্রকাশিত হওয়া খসড়া থেকে একটি স্নিপেট এখানে রয়েছে:
— এভার্ট
1
আমি আপনার সাথে একমত নই যে এটি বর্তমানে প্রকাশিত আরএফসি-এর মধ্যে অস্পষ্ট, তবে আপনি যদি আমাকে বিশ্বাস না করেন তবে আমি লেখককে তাদের ডিলেট এবং জিইটির অভিপ্রায় জিজ্ঞাসা করার জন্য আমন্ত্রণ জানাব would আপনি দেখতে পাবেন যে এটি আমার উত্তরের সাথে মিলিয়েছে। আপনার মতো আমিও মানসম্পন্ন সংস্থাগুলিতে জড়িত এবং আরএফসির ব্যাখ্যা কীভাবে করা উচিত সে সম্পর্কে আমি একটি মতামত সহকারে একাকী ব্যক্তি নই।
— এভার্ট
2
যদি এটি হয় তবে 7231 টি খারাপ শব্দযুক্ত, এবং "পেলড বডিটি অবহেলা করা উচিত" বলা উচিত ছিল। আপনি উপরোক্ত কোন খসড়াটি উল্লেখ করছেন?
— Alnitak
3

যদি কেউ এই সমস্যাটির পরীক্ষায় চলেছে তবে তা সর্বজনীনভাবে সমর্থনযোগ্য নয়।

আমি বর্তমানে সহি প্রো সাথে পরীক্ষা করছি এবং এটি খুব স্পষ্ট যে কোনও পোস্ট ডিলিট কল কোনও প্রদত্ত বডি ডেটা (এন্ডপয়েন্ট ডিজাইন অনুযায়ী বাল্কে মুছতে আইডির একটি বৃহত তালিকা) কেটে যায়।

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

আমি নিশ্চিত যে সহি এটি সমর্থন করে না, এবং আমি স্যুট অনুসরণ করার মতো আরও অনেক সরঞ্জাম কল্পনা করব।

— পার্কার
সূত্র
এটি সহি প্রো এর সর্বশেষ সংস্করণে প্রয়োগ করা হয়েছে। যেহেতু সহি এইচটিটিপি কল করতে জাভা ব্যবহার করে, এবং জাভাটির ১.৮ সংস্করণের পূর্বে একটি বাগ ছিল যা ব্যবহারকারীকে ডিলেট করার অনুরোধ করতে দেবে না। সুতরাং জাভা 1.8 এর পরে এবং সহি প্রো 6.1.1 (শিগগিরই প্রকাশ্য হওয়া) সহ লোকেরা সহিতে শরীরের সাথে অনুরোধ করতে পারে।
— বিবেক ভি দ্বিবেদী
-1

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

https://github.com/ashish720/spring-examples

— আশিস
সূত্র
-1

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

— Dattatray
সূত্র
3
তারা যোগ্যতার কথা নয়, মানদণ্ডের কথা বলছে। আপনার শরীরের সাথে একটি জিইটি অনুরোধও থাকতে পারে, যা ভাল নয়
— রেজা 21
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.