क्या एक इकाई निकाय को HTTP DELETE अनुरोध के लिए अनुमति है?

717

HTTP DELETE अनुरोध जारी करते समय, अनुरोध URI को हटाने के लिए संसाधन की पूरी तरह से पहचान करनी चाहिए। हालांकि, क्या यह अनुरोध के निकाय निकाय के हिस्से के रूप में अतिरिक्त मेटा-डेटा जोड़ने के लिए अनुमति है?

http rest

— Haacked
स्रोत

4

ASP.NET में WebApi 2 FromBody पैरामीटर्स को HttpDelete एंडपॉइंट्स के लिए अनदेखा किया जाता है।

— जेनी ओ'रिली ने

2

मुझे एक समान चिंता है, लेकिन मेरा मामला अलग है। जब मैं सौ वस्तुओं को हटाना चाहता हूं तो मैं एक बैच डिलीट अनुरोध जारी करना चाहता हूं। निश्चित रूप से यह पूर्व HTTP 2.0 नेटवर्क के लिए एक शानदार प्रदर्शन को बढ़ावा देने वाला है।

— सिंगागुलर

1

क्या HTTP / 2 में कोई बदलाव हुआ है?

— ज्योतमान सिंह

570

कल्पना स्पष्ट रूप से मना नहीं करती है या इसे हतोत्साहित नहीं करती है, इसलिए मैं कहना चाहूंगा कि इसकी अनुमति है।

Microsoft इसे उसी तरह से देखता है (मैं दर्शकों में बड़बड़ा सकता है), वे MSDN लेख में ADO.NET डेटा सेवा रूपरेखा के DELETE विधि के बारे में बताते हैं :

यदि एक DELETE अनुरोध में एक निकाय शामिल है, तो निकाय को अनदेखा किया जाता है [...]

इसके अतिरिक्त यहां RFC2616 (HTTP 1.1) को अनुरोधों के संबंध में क्या कहना है:

एक निकाय-निकाय केवल तब मौजूद होता है जब एक संदेश-निकाय मौजूद होता है (धारा 7.2)
एक की उपस्थिति संदेश शरीर एक के शामिल किए जाने से संकेत है Content-Lengthया Transfer-Encodingहैडर (धारा 4.3)
एक संदेश-निकाय को तब शामिल नहीं किया जाना चाहिए जब अनुरोध विधि का विनिर्देश इकाई-निकाय भेजने की अनुमति नहीं देता (धारा 4.3)
एक निकाय निकाय को केवल TRACE अनुरोधों में स्पष्ट रूप से मना किया गया है, अन्य सभी अनुरोध प्रकार अप्रतिबंधित हैं (धारा 9, और विशेष रूप से 8.8)

प्रतिक्रियाओं के लिए, इसे परिभाषित किया गया है:

क्या एक संदेश शरीर शामिल किया गया है दोनों अनुरोध विधि पर निर्भर करता है और प्रतिसाद स्थिति (धारा 4.3)
HEAD अनुरोधों (धारा 9, और 9.4 विशेष रूप से) के जवाब में एक संदेश-निकाय को स्पष्ट रूप से मना किया गया है
1xx (सूचनात्मक), 204 (कोई सामग्री नहीं), और 304 (संशोधित नहीं) प्रतिक्रियाओं (धारा 4.3) में एक संदेश-निकाय को स्पष्ट रूप से मना किया गया है
अन्य सभी प्रतिक्रियाओं में एक संदेश-निकाय शामिल है, हालांकि यह शून्य लंबाई का हो सकता है (खंड 4.3)

— Tomalak
स्रोत

7

@ जेसन निश्चित रूप से। आप अतिरिक्त डेटा पास करने के लिए कस्टम हेडर का भी उपयोग कर सकते हैं, लेकिन अनुरोध निकाय का उपयोग क्यों नहीं करते।

— तोमलक

86

हालाँकि यह कल्पना संदेश-निकाय होने से DELETE के अनुरोध को मना नहीं करती है, खंड 4.3 से यह संकेत मिलता है कि शरीर को सर्वर द्वारा अनदेखा किया जाना चाहिए क्योंकि DELETE इकाई-निकायों के लिए कोई "परिभाषित शब्दार्थ" नहीं हैं: "एक सर्वर SHODD पढ़ें और आगे भेजें किसी भी अनुरोध पर संदेश-निकाय; यदि अनुरोध पद्धति में निकाय-निकाय के लिए परिभाषित शब्दार्थ शामिल नहीं हैं, तो अनुरोध को संभालते समय संदेश-निकाय को अनदेखा किया जाना चाहिए । "

— शेल्ली

72

कृपया ध्यान दें कि बहुत सारे ग्राहक एक बॉडी के साथ DELETE भेजने में भी असमर्थ हैं। यह सिर्फ मुझे Android पर जला दिया।

— कार्मिक कोडर

1

@ कर्मचक्र: महान बिंदु। अधिक जानकारी: Android में HTTP DELETE अनुरोध भेजना ।

— एमएस डौस्ती

2

HTTP कल्पना के साथ मिश्रित कार्यान्वयन के बारे में बहुत सारी चर्चा। ग्राहक चीजों को उस तरीके से लागू करेंगे जिस तरह से वे कल्पना की व्याख्या करते हैं, इस कल्पना के अर्थ के साथ भ्रमित न करें। तथ्य यह है कि कल्पना इस अस्पष्ट छोड़ देता है। मैं इस व्याख्या से असहमत हूं कि क्योंकि निकाय-निकाय के लिए कोई परिभाषित शब्दार्थ नहीं है कि इसमें निहितार्थ है कि इसे अनदेखा किया जाना चाहिए। मुझे लगता है कि लोग उन विशिष्ट व्याख्याओं से पीछे की ओर काम कर रहे हैं जो मौजूद हैं (जर्सी, एंड्रॉइड टेस्ट क्लाइंट, आदि) और कल्पना को सच करने के बजाय व्याख्या को सही ठहराने की कोशिश कर रहे हैं। मनुष्य पतित हैं।

— जिब्रॉन

169

HTTP 1.1 विनिर्देशन ( RFC 7231 ) का नवीनतम अपडेट स्पष्ट रूप से एक DELETE अनुरोध में एक निकाय निकाय को अनुमति देता है:

DELETE अनुरोध संदेश के भीतर एक पेलोड कोई परिभाषित शब्दार्थ नहीं है; DELETE अनुरोध पर पेलोड बॉडी भेजने से अनुरोध को अस्वीकार करने के लिए कुछ मौजूदा कार्यान्वयन हो सकते हैं।

— grzes
स्रोत

3

कल्पना के नवीनतम संयुक्त राष्ट्र अनुमोदित संस्करण इस आवश्यकता को हटा देता है। नवीनतम स्वीकृत संस्करण अभी भी ऊपर उद्धृत RFC2616 है।

— बिशप

4

कौन सा संस्करण? संस्करण 20 में अभी भी वही संस्करण है जो संस्करण 19 से जुड़ा हुआ है: "DELETE अनुरोधों पर निकायों का कोई परिभाषित शब्दार्थ नहीं है। ध्यान दें कि DELETE अनुरोध पर एक निकाय भेजने से अनुरोध को अस्वीकार करने के लिए कुछ मौजूदा कार्यान्वयन हो सकते हैं।"

— grzes

11

संस्करण 26 सुझाव है कि आप एक शरीर की अनुमति दे सकते हैं:

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

RFC 7231 सेक्शन 4.3.5 , संस्करण 26 के साथ भाषा को अंतिम रूप देता है A payload within a DELETE request message has no defined semantics। तो शरीर को अनुमति है।

— mndrix

6

शरीर की अनुमति है लेकिन अनुरोध के लिए प्रासंगिक नहीं होना चाहिए। इसका उपयोग करने का कोई मतलब नहीं है।

— एवर्ट

54

Tomcat और Jetty के कुछ संस्करण मौजूद होने पर एक निकाय निकाय की उपेक्षा करते हैं। यदि आप इसे प्राप्त करने का इरादा रखते हैं, तो यह एक उपद्रव हो सकता है।

— evan.leonard
स्रोत

2

Google ऐप इंजन, अनुरोध निकाय के बजाय एक खाली डिफ़ॉल्ट इकाई को तत्काल भेज देता है और पास कर देता है।

— ओलिवर हॉसलर

Tomcat के बारे में अधिक जानकारी: Apache Tomcat को DELETE विधि कैसे स्वीकार करें ।

— एमएस डौस्ती

50

हटाने के अनुरोध में शरीर का उपयोग करने का एक कारण आशावादी संगरोध नियंत्रण के लिए है।

आप रिकॉर्ड के संस्करण 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

GET (और DELETE) में निकायों के स्पष्ट रूप से HTTP और REST के साथ गलत व्यवहार हो रहा है। संगामिति नियंत्रण से निपटने के लिए अन्य तंत्र हैं (उदाहरण के लिए यदि संशोधित-बाद और etags)।

— ब्रूनो

19

जब यह कल्पना DELETE में शरीर को मना नहीं करती है, तो यह स्पष्ट रूप से कैसे गलत है?

— नील मैकगिगन

5

क्योंकि आप शरीर के साथ कुछ भी करने के लिए नहीं हैं। देखें: stackoverflow.com/a/983458/372643

— ब्रूनो

14

यह वास्तव में एक ही मुद्दा है: GET आपको URI द्वारा पहचाने गए संसाधन के प्रतिनिधित्व को पुनः प्राप्त करने की अनुमति देता है, और DELETE URI द्वारा पहचाने गए संसाधन को हटा देता है। यदि आप विशिष्ट संस्करण हटाना चाहते हैं, तो अन्य संस्करणों के लिए एक अलग URI का उपयोग करें। HTTP / REST में URI संसाधन का एकमात्र पहचानकर्ता होना चाहिए। हेडर में मेटाडेटा का उपयोग करें यदि आपको कंसीडर को हैंडल करने की आवश्यकता है (उदाहरण के लिए , If-Unmodified-Sinceया Etag, यही वह है)।

— ब्रूनो

5

एक शरीर में एक संस्करण क्षेत्र के बजाय ETag हेडर का उपयोग करें

— malhal

26

यह मुझे प्रतीत होता है कि RFC 2616 इसे निर्दिष्ट नहीं करता है।

खंड 4.3 से:

अनुरोध के संदेश-हेडर में सामग्री-लंबाई या स्थानांतरण-एन्कोडिंग हेडर फ़ील्ड के शामिल होने से एक अनुरोध में एक संदेश-निकाय की उपस्थिति का संकेत मिलता है। यदि अनुरोध विधि (खंड 5.1.1) के विनिर्देश अनुरोध में एक निकाय-निकाय को भेजने की अनुमति नहीं देता है, तो एक संदेश-निकाय अनुरोध में शामिल नहीं होना चाहिए। एक सर्वर किसी भी अनुरोध पर संदेश-निकाय को पढ़ता और अग्रेषित करता है; यदि अनुरोध विधि में निकाय-निकाय के लिए परिभाषित शब्दार्थ शामिल नहीं हैं, तो अनुरोध को संभालते समय संदेश-निकाय SHOULD को अनदेखा किया जाना चाहिए।

और धारा 9.7:

DELETE विधि अनुरोध करती है कि मूल सर्वर अनुरोध-URI द्वारा पहचाने गए संसाधन को हटा दें। इस विधि को मूल सर्वर पर मानव हस्तक्षेप (या अन्य साधनों) द्वारा ओवरराइड किया जाना चाहिए। क्लाइंट को गारंटी नहीं दी जा सकती है कि ऑपरेशन किया गया है, भले ही स्थिति कोड मूल सर्वर से लौटा हो यह इंगित करता है कि कार्रवाई सफलतापूर्वक पूरी हो गई है। हालाँकि, जब तक प्रतिक्रिया नहीं दी जाती, तब तक सर्वर SHOULD सफलता का संकेत नहीं देता, यह संसाधन को हटाने या इसे दुर्गम स्थान पर ले जाने का इरादा रखता है।

एक सफल प्रतिक्रिया 200 होना चाहिए (ठीक है) यदि प्रतिक्रिया में स्थिति का वर्णन करने वाली एक इकाई शामिल है, 202 (स्वीकृत) यदि कार्रवाई अभी तक लागू नहीं हुई है, या 204 (कोई सामग्री नहीं) यदि कार्रवाई अधिनियमित की गई है, लेकिन प्रतिक्रिया में शामिल नहीं है एक इकाई।

यदि अनुरोध कैश से गुजरता है और अनुरोध-यूआरआई एक या अधिक वर्तमान में कैश्ड संस्थाओं की पहचान करता है, तो उन प्रविष्टियों को बासी माना जाएगा। इस विधि के जवाब cacheable.c नहीं हैं

तो यह स्पष्ट रूप से अनुमत या अस्वीकृत नहीं है, और एक मौका है कि जिस तरह से एक प्रॉक्सी संदेश शरीर को हटा सकता है (हालांकि इसे पढ़ा और इसे अग्रेषित करना चाहिए)।

— एडम रोसेनफील्ड
स्रोत

19

यदि आप अपने DELETE अनुरोध में एक निकाय की आपूर्ति करते हैं और एक Google क्लाउड HTTPS लोड बैलेंसर का उपयोग कर रहे हैं, तो यह 400 त्रुटि के साथ आपके अनुरोध को अस्वीकार कर देगा। मैं एक दीवार के खिलाफ अपना सिर पीट रहा था और पता चला कि Google, जो भी कारण से, एक शरीर के साथ एक DELETE अनुरोध एक विकृत अनुरोध है।

— बेन फ्राइड
स्रोत

1

for whatever reason- क्योंकि कल्पना ऐसा कहती है: पी

— मर्डोक्स

20

युक्ति "ऐसा नहीं कहती है" यह सिर्फ यह कहता है कि शरीर विशेष रूप से परिभाषित नहीं है। यदि यह परिभाषित नहीं है, और आप इसे अनदेखा करना चाहते हैं, तो शांत करें ... आगे बढ़ें और इसे अनदेखा करें। लेकिन एकमुश्त अनुरोध को अस्वीकार करना अत्यधिक और अनावश्यक लगता है।

— बेन फ्राइड

1

अपरिभाषित व्यवहार पर भरोसा न करें। यह एक बहुत अच्छा सबसे अच्छा अभ्यास है।

— एवर्ट

@ वहाँ स्पष्ट रूप से अपरिभाषित व्यवहार है (जैसे कि आप उदाहरण के लिए सी भाषा की विशिष्टताओं में वर्णन देखते हैं) और ऐसा व्यवहार है जिसकी अनुमति है लेकिन बस वर्णित नहीं है। एक संदेश निकाय का उपयोग करना DELETEबाद का है।

— अलनीतक

9

यह ध्यान देने योग्य है कि संस्करण 3.0 के लिए ओपनएपीआई विनिर्देश ने एक निकाय के साथ DELETE विधियों के लिए समर्थन को गिरा दिया:

संदर्भ के लिए यहां और यहां देखें

यह भविष्य में इन एपीआई के आपके कार्यान्वयन, प्रलेखन, या उपयोग को प्रभावित कर सकता है।

— CleverPatrick
स्रोत

7

ऐसा लगता है कि ElasticSearch इसका उपयोग करता है: https://www.elastic.co/guide/en/elasticsearch/reference/5.x/search-request-scroll.html#_clear_scroll_api

जिसका मतलब है कि नेति इसका समर्थन करती है।

टिप्पणियों में उल्लिखित की तरह यह अब मामला नहीं हो सकता है

— सेबस्टियन लॉर्बर
स्रोत

1

यदि आप Apache http क्लाइंट का उपयोग करते हैं तो आप आसानी से HttpEntityEnclosingRequestBase को बढ़ाकर और getMethod () विधि रिटर्न GET या DELETE बनाकर GET और DELETE के अपने संस्करण बना सकते हैं। हम इसे एलेस्टिक्स की खोज के लिए बात करने के लिए उपयोग करते हैं।

— जिल्स वैन गुरप

2

मृत लिंक - महान। हमें उन लिंक उत्तरों की अधिक आवश्यकता है - नहीं

— कॉटन

3

लिंक किए गए दस्तावेज़ में अब केवल POST अनुरोध हैं, कोई DELETE नहीं है। इस उत्तर में एक नोट जोड़ने लायक हो सकता है?

— dshepherd

एलिटिक्स खोज GET अनुरोधों के साथ भी शरीर का उपयोग करती है।

— निधिन डेविड

7

HTTP मेलिंग सूची पर रॉय फील्डिंग स्पष्ट करती है कि http मेलिंग सूची https://lists.w3.org/Archives/Public/ietf-http-wg/2020JanMar/0123.html और कहती है:

GET / DELETE निकाय को अनुरोध के प्रसंस्करण या व्याख्या पर कोई भी प्रभाव डालने के लिए बिल्कुल निषिद्ध है

इसका मतलब यह है कि शरीर को सर्वर के व्यवहार को संशोधित नहीं करना चाहिए। फिर वह कहते हैं:

संदेश फ़्रेमिंग को बनाए रखने के लिए प्राप्त बाइट्स को पढ़ने और त्यागने की आवश्यकता से अलग।

और अंत में शरीर को मना न करने का कारण:

केवल एक ही कारण है कि हम एक शरीर भेजने से मना नहीं किया है क्योंकि यह आलसी कार्यान्वयन के लिए कोई शरीर भेजा जाएगा संभालने है।

इसलिए जब ग्राहक पेलोड बॉडी भेज सकते हैं, सर्वरों को इसे छोड़ देना चाहिए और एपीआई को उन अनुरोधों पर पेलोड बॉडी के लिए सिमेंटिक को परिभाषित नहीं करना चाहिए।

— रॉबर्टो पोली
स्रोत

5

यह परिभाषित नहीं है ।

DELETE अनुरोध संदेश के भीतर एक पेलोड कोई परिभाषित शब्दार्थ नहीं है; DELETE अनुरोध पर पेलोड बॉडी भेजने से अनुरोध को अस्वीकार करने के लिए कुछ मौजूदा कार्यान्वयन हो सकते हैं।
https://tools.ietf.org/html/rfc7231#page-29

— सिमोन जिन
स्रोत

विशेष रूप से, RFC 7231 सेक्शन 4.3.5

— mndrix

3

यह सटीक उद्धरण पहले से ही पिछले उत्तरों में शामिल था, इस उत्तर को हटा दिया जाना चाहिए।

— मद्रबेक

5

एक बॉडी के साथ DELETE का उपयोग करना जोखिम भरा है ... मैं REST पर सूची संचालन के लिए इस दृष्टिकोण को प्राथमिकता देता हूं:

नियमित संचालन

GET / वस्तुएं / सभी वस्तुओं हो जाता है

GET / ऑब्जेक्ट / ID निर्दिष्ट ID के साथ एक ऑब्जेक्ट हो जाता है

पोस्ट / ऑब्जेक्ट एक नई वस्तु जोड़ता है

PUT / ऑब्जेक्ट / ID निर्दिष्ट आईडी के साथ एक वस्तु जोड़ता है, एक वस्तु को अपडेट करता है

DELETE / ऑब्जेक्ट / ID निर्दिष्ट आईडी के साथ ऑब्जेक्ट को हटाता है

सभी कस्टम क्रियाएं POST हैं

POST / वस्तुओं / AddList शरीर में शामिल वस्तुओं की एक सूची या सरणी जोड़ता है

POST / ऑब्जेक्ट्स / डिलीट डिलीट बॉडी में शामिल ऑब्जेक्ट्स की एक सूची को हटाता है

POST / ऑब्जेक्ट्स / customQuery शरीर में कस्टम क्वेरी के आधार पर एक सूची बनाता है

यदि कोई ग्राहक आपके विस्तारित ऑपरेशन का समर्थन नहीं करता है तो वे नियमित रूप से काम कर सकते हैं।

— एलीएज़र गरज़ा
स्रोत

POSTनए संसाधनों को बनाने के लिए a का उपयोग करना एक अच्छा RESTy तरीका नहीं है क्योंकि POST प्रतिक्रियाओं का शब्दार्थ स्पष्ट नहीं है, विशेष रूप से स्थान हेडर के संदर्भ में। आप अनिवार्य रूप से HTTP को पीछे छोड़ रहे हैं और शीर्ष पर RPC को रोकते हैं। उचित "HTTP / REST रास्ता" PUTडब्ल्यू / If-None-Match: *हेडर (या उचित HTTP विधियों को देखना, MKCOLआदि देखना ) का उपयोग करके संसाधन बनाना है ।

— होन

4

मुझे नहीं लगता कि इसका कोई अच्छा जवाब पोस्ट किया गया है, हालांकि मौजूदा उत्तरों पर बहुत सारी शानदार टिप्पणियां हैं। मैं उन टिप्पणियों के सार को एक नए उत्तर में उठाऊंगा:

RFC7231 के इस पैराग्राफ को कुछ बार उद्धृत किया गया है, जो इसे योग करता है।

DELETE अनुरोध संदेश के भीतर एक पेलोड कोई परिभाषित शब्दार्थ नहीं है; DELETE अनुरोध पर पेलोड बॉडी भेजने से अनुरोध को अस्वीकार करने के लिए कुछ मौजूदा कार्यान्वयन हो सकते हैं।

अन्य उत्तरों से मुझे जो याद आया वह निहितार्थ था। हां, यह DELETEअनुरोधों पर एक निकाय को शामिल करने की अनुमति है , लेकिन यह अर्थहीन रूप से अर्थहीन है। इसका वास्तव में मतलब यह है कि DELETEअनुरोध निकाय के साथ एक अनुरोध जारी करना शब्दगत रूप से अनुरोध निकाय को शामिल नहीं करने के बराबर है।

एक अनुरोध निकाय को शामिल करने से अनुरोध पर कोई प्रभाव नहीं पड़ना चाहिए, इसलिए इसमें शामिल होने का कोई मतलब नहीं है।

tl; dr: तकनीकी रूप DELETEसे एक अनुरोध निकाय के साथ अनुरोध की अनुमति है, लेकिन ऐसा करना कभी उपयोगी नहीं होता है।

— एवर्ट
स्रोत

2

"शब्दार्थ अर्थहीन" का अर्थ यह नहीं है कि "कोई परिभाषित शब्दार्थ नहीं है"। पूर्व का अर्थ है कि इसका कोई अर्थ नहीं हो सकता है। उत्तरार्द्ध का सीधा मतलब है कि RFC स्वयं निर्दिष्ट नहीं करता है कि वे शब्दार्थ क्या हो सकते हैं। (मैं आरएफसी लिखता हूं)

— Alnitak

1

दूसरे शब्दों में, यदि एपीआई का कार्यान्वयन करने वाला अपने लिए कुछ शब्दार्थ परिभाषित करने की इच्छा रखता है, तो वे ऐसा करने के लिए पूरी तरह से स्वतंत्र हैं।

— अलनीतक

1

@ अलनीतक यह निश्चित रूप से एक गलत व्याख्या है। उस परिभाषा के द्वारा किसी भी HTTP अनुरोध निकाय में कोई परिभाषित शब्दार्थ नहीं है, लेकिन DELETE और GET को विशेष रूप से विनिर्देशन में कहा जाता है। : यहाँ एक अभी तक किया जा प्रकाशित मसौदा से एक टुकड़ा विशेष रूप से GET अनुरोध के बारे में इस बारे में बात कर रहा है

— एवर्ट

1

मैं आपसे असहमत नहीं हूं कि वर्तमान में जारी RFC में यह स्पष्ट नहीं है, लेकिन यदि आप मुझ पर विश्वास नहीं करते हैं, तो मैं आपको DELETE और GET के लिए उनके इरादे के बाद लेखकों से पूछने के लिए आमंत्रित करूंगा। आप पाएंगे कि यह मेरे उत्तर के साथ है। आपकी तरह, मैं भी मानक निकायों में शामिल हूं और मैं केवल एक अकेला व्यक्ति नहीं हूं कि इस बारे में राय कैसे आरएफसी की व्याख्या की जानी चाहिए।

— एवर्ट

2

अगर ऐसा है, तो 7231 खराब रूप से शब्द है, और कहा जाना चाहिए "पेलोड बॉडी एमयूएस को नजरअंदाज किया जाना चाहिए"। आप ऊपर किस ड्राफ्ट का उल्लेख कर रहे हैं?

— अलंकृत

3

यदि कोई इस मुद्दे की जाँच में भाग ले रहा है, तो यह सार्वभौमिक रूप से समर्थित नहीं है।

मैं वर्तमान में साही प्रो के साथ परीक्षण कर रहा हूं और यह बहुत स्पष्ट रूप से एक http DELETE कॉल स्ट्रिप्स है जो किसी भी प्रदान किए गए शरीर के डेटा (आईडीपॉइंट के अनुसार थोक में हटाने के लिए आईडी की एक बड़ी सूची) है।

मैं उनके साथ कई बार संपर्क में रहा हूं और साथ ही तीन अलग-अलग पैकेज के स्क्रैप, चित्र, लॉग इन के लिए उन्हें समीक्षा के लिए भेजा गया है और उन्होंने अभी भी इसकी पुष्टि नहीं की है। एक असफल पैच, और बाद में उनके समर्थन से एक मिस्ड कॉन्फ्रेंस कॉल और मुझे अभी भी एक ठोस जवाब नहीं मिला है।

मुझे यकीन है कि साही इसका समर्थन नहीं करता है, और मुझे लगता है कि कई अन्य उपकरण सूट का पालन करेंगे।

— पार्कर
स्रोत

इसे साही प्रो के नवीनतम संस्करण में लागू किया गया है। चूंकि साही HTTP कॉल करने के लिए जावा का उपयोग करता है, और जावा में संस्करण 1.8 से पहले एक बग था जो उपयोगकर्ता को एक DELETE अनुरोध करने की अनुमति नहीं देगा। तो जावा 1.8 के बाद और साही प्रो 6.1.1 (जल्द ही सार्वजनिक होने के लिए), लोग साही में निकाय के साथ DELETE अनुरोध कर सकते हैं।

— विवेक वी। द्विवेदी

-1

नीचे हो सकता है GitHUb url आपकी मदद करेगा, जवाब पाने के लिए। दरअसल, Tomcat, Weblogic जैसे एप्लिकेशन सर्वर अनुरोध पेलोड के साथ HTTP.DELETE कॉल से इनकार करते हैं। इसलिए इन सभी बातों को ध्यान में रखते हुए, मैंने जीतूब में उदाहरण जोड़ा है, कृपया इस पर एक नज़र डालें

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

— आशीष
स्रोत

-1

मैं एक अनुरोध निकाय के साथ DELETE संचालन को लागू करने में सक्षम था। मैंने AWS लैम्ब्डा और AWS API गेटवे का उपयोग किया और गो भाषा का उपयोग किया।

— दत्तात्रेय
स्रोत

3

वे मानकों की बात कर रहे हैं, क्षमता की नहीं। आप शरीर के साथ GET अनुरोध भी कर सकते हैं, जो अच्छा नहीं है

— ReZa