หน่วยงานที่ได้รับอนุญาตสำหรับคำขอ HTTP DELETE หรือไม่

717

เมื่อออกคำขอ HTTP DELETE URI คำขอควรระบุทรัพยากรที่จะลบอย่างสมบูรณ์ อย่างไรก็ตามอนุญาตให้เพิ่ม meta-data พิเศษเป็นส่วนหนึ่งของเอนทิตีของคำขอได้หรือไม่

http rest

— Haacked
แหล่งที่มา

4

ใน ASP.NET WebApi 2 จากพารามิเตอร์ร่างกายจะถูกละเว้นสำหรับ HttpDelete endppoints

— Jenny O'Reilly

2

ฉันมีความกังวลคล้ายกัน แต่กรณีของฉันแตกต่างกัน ฉันต้องการส่งคำขอลบแบทช์เมื่อฉันต้องการลบวัตถุนับร้อยรายการ แน่นอนว่าเป็นการเพิ่มประสิทธิภาพที่ยอดเยี่ยมสำหรับเครือข่าย HTTP 2.0 ล่วงหน้า

— Singagirl

1

HTTP / 2 มีการเปลี่ยนแปลงบ้างไหม?

— Jyotman Singh เมื่อ

570

สเป็คไม่ได้ห้ามหรือกีดกันอย่างชัดเจนดังนั้นฉันมักจะบอกว่ามันได้รับอนุญาต

Microsoft เห็นด้วยวิธีเดียวกัน (ฉันสามารถได้ยินเสียงพึมพำต่อผู้ชม) พวกเขาระบุไว้ในบทความ MSDN เกี่ยวกับวิธีการลบของ ADO.NET Data Services Framework :

หากคำขอ DELETE มีเนื้อหาขององค์กรเนื้อหาจะถูกละเว้น [... ]

นอกจากนี้นี่คือสิ่งที่RFC2616 (HTTP 1.1) ได้กล่าวเกี่ยวกับคำขอ:

นิติบุคคลร่างกายมีอยู่เฉพาะเมื่อมีข้อความร่างกายเป็นปัจจุบัน (มาตรา 7.2)
การปรากฏตัวของข้อความ - ข้อความเป็นสัญญาณโดยรวมของContent-LengthหรือTransfer-Encodingส่วนหัว (ส่วน 4.3)
ข้อความร่างกายจะต้องไม่ถูกรวมไว้เมื่อข้อกำหนดของวิธีการร้องขอไม่อนุญาตให้มีการส่งนิติบุคคลร่างกาย (มาตรา 4.3)
ร่างกายนิติบุคคลเป็นสิ่งต้องห้ามอย่างชัดเจนในการติดตามคำขอเท่านั้นทุกประเภทคำขออื่น ๆ จะไม่ จำกัด (มาตรา 9 และ 9.8 โดยเฉพาะ)

สำหรับการตอบกลับสิ่งนี้ได้ถูกกำหนดไว้แล้ว:

การรวมเนื้อหาข้อความนั้นขึ้นอยู่กับทั้งวิธีการร้องขอและสถานะการตอบกลับ (ส่วนที่ 4.3)
ข้อความร่างกายเป็นสิ่งต้องห้ามอย่างชัดเจนในการตอบสนองต่อการร้องขอ HEAD (มาตรา 9 และ 9.4 โดยเฉพาะ)
ข้อความร่างกายเป็นสิ่งต้องห้ามอย่างชัดเจนใน 1xx (ข้อมูล), 204 (ไม่มีเนื้อหา) และ 304 (ไม่ได้แก้ไข) การตอบสนอง (ส่วน 4.3)
การตอบกลับอื่น ๆ ทั้งหมดรวมถึงเนื้อหาของข้อความแม้ว่ามันอาจจะมีความยาวเป็นศูนย์ (มาตรา 4.3)

— Tomalak
แหล่งที่มา

7

@ Jason แน่นอน คุณสามารถใช้ส่วนหัวที่กำหนดเองเพื่อส่งผ่านข้อมูลเพิ่มเติม แต่ทำไมไม่ใช้เนื้อหาของคำขอ

— Tomalak

86

แม้ว่าข้อมูลจำเพาะจะไม่ห้ามการร้องขอ DELETE จากการมีเนื้อหาของข้อความส่วนที่ 4.3ดูเหมือนว่าบ่งชี้ว่าเซิร์ฟเวอร์ควรละเว้นเนื้อหาเนื่องจากไม่มี "semantics ที่กำหนด" สำหรับการลบเอนทิตีเนื้อความ: "เซิร์ฟเวอร์ควรอ่านและส่งต่อ ข้อความเนื้อหาในการร้องขอใด ๆหากวิธีการร้องขอไม่รวมถึงความหมายที่กำหนดไว้สำหรับนิติบุคคล - ร่างกายแล้วข้อความร่างกายควรจะถูกละเว้นเมื่อจัดการคำขอ "

— เชลลีย์

72

โปรดทราบว่าลูกค้าจำนวนมากยังไม่สามารถส่ง DELETE ที่มีเนื้อหาได้ นี่เพิ่งเผาฉันใน Android

— Karmic Coder

1

@KarmicCoder: จุดที่ดี ข้อมูลเพิ่มเติม: ส่ง HTTP คำขอลบใน Android

— MS Dousti

2

มีการพูดคุยมากมายเกี่ยวกับการใช้งานแบบผสมกับข้อมูลจำเพาะ HTTP ลูกค้าจะใช้สิ่งต่าง ๆ ในวิธีที่พวกเขาตีความสเป็คอย่าสับสนกับความหมายของสเป็ค ความจริงก็คือสเป็คออกจากนี้คลุมเครือ ฉันไม่เห็นด้วยกับการตีความว่าเนื่องจากไม่มีความหมายที่กำหนดไว้สำหรับเอนทิตี้ของร่างกายที่มีความหมายว่าควรละเว้น ฉันคิดว่าคนกำลังทำงานย้อนกลับจากการตีความเฉพาะลูกค้าที่มีอยู่ (Jersey, Android ลูกค้าทดสอบ ฯลฯ ) และพยายามที่จะปรับการตีความมากกว่าความพยายามที่จะเป็นจริงเพื่อสเป็ค มนุษย์มีความผิดพลาด

— Gibron

169

การอัปเดตล่าสุดของข้อมูลจำเพาะ HTTP 1.1 ( RFC 7231 ) อนุญาตให้องค์กรอย่างชัดเจนในคำขอ DELETE:

เพย์โหลดภายในข้อความคำขอลบไม่มีความหมายที่กำหนดไว้ การส่งส่วนของส่วนของข้อมูลบนคำขอ DELETE อาจทำให้การใช้งานที่มีอยู่บางส่วนปฏิเสธคำขอ

— grzes
แหล่งที่มา

3

ข้อมูลจำเพาะรุ่นที่ไม่ผ่านการอนุมัติล่าสุดจะลบข้อกำหนดนี้ รุ่นที่ได้รับการรับรองล่าสุดยังคงเป็น RFC2616 ที่ยกมาข้างต้น

— BishopZ

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สามารถมีร่างกายได้

— Pure.Krome

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 App Engine สร้างอินสแตนซ์และส่งเอนทิตีเริ่มต้นที่ว่างเปล่าแทนการร้องขอเนื้อหา

— Oliver Hausler

ข้อมูลเพิ่มเติมเกี่ยวกับ Tomcat: วิธีที่จะทำให้ Apache Tomcat ยอมรับวิธีการลบ

— MS Dousti

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

โปรดสังเกตว่าแต่ละข้อความมีเวอร์ชันของตัวเอง บางทีคุณสามารถระบุหลาย ๆ รุ่นโดยใช้หลายหัว แต่โดย George นี่ง่ายกว่าและสะดวกกว่ามาก

ใช้งานได้กับ Tomcat (7.0.52) และ Spring MVC (4.05) ซึ่งอาจเป็นเวอร์ชั่นก่อนหน้านี้เช่นกัน:

@RestController
public class TestController {

    @RequestMapping(value="/echo-delete", method = RequestMethod.DELETE)
    SomeBean echoDelete(@RequestBody SomeBean someBean) {
        return someBean;
    }
}

— Neil McGuigan
แหล่งที่มา

15

การมีเนื้อความใน GET (และ DELETE) นั้นทำให้ HTTP และ REST ผิดพลาดอย่างชัดเจน มีกลไกอื่น ๆ สำหรับจัดการกับการควบคุมภาวะพร้อมกัน (เช่น If-Modified-Since และ etags)

— บรูโน่

19

มันชัดเจนว่าทำผิดมันได้อย่างไรเมื่อ spec ไม่ได้ห้ามร่างกายใน DELETE?

— Neil McGuigan

5

เพราะคุณไม่ได้ตั้งใจทำอะไรกับร่างกาย ดู: stackoverflow.com/a/983458/372643

— บรูโน่

14

นี่เป็นปัญหาเดียวกัน: GET ช่วยให้คุณสามารถดึงข้อมูลการนำเสนอของทรัพยากรที่ระบุโดย URI และลบลบทรัพยากรที่ระบุโดย URI ใช้ URI อื่นสำหรับเวอร์ชันอื่นถ้าคุณต้องการลบเวอร์ชันที่ระบุ URI ควรเป็นตัวระบุเพียงอย่างเดียวของทรัพยากรใน HTTP / REST ใช้ข้อมูลเมตาในส่วนหัวหากคุณต้องการจัดการกับการเกิดพร้อมกัน (เช่นIf-Unmodified-SinceหรือEtagนั่นคือสิ่งที่พวกเขากำลังทำ)

— บรูโน่

5

ใช้ส่วนหัว ETag แทนฟิลด์เวอร์ชันในเนื้อหา

— malhal

26

สำหรับฉันแล้วดูเหมือนว่าRFC 2616ไม่ได้ระบุสิ่งนี้

จากส่วนที่ 4.3:

การปรากฏตัวของเนื้อความในคำขอมีการส่งสัญญาณโดยการรวมของส่วนหัวของเนื้อหาความยาวหรือการถ่ายโอนการเข้ารหัสในส่วนหัวของข้อความของคำขอ ต้องไม่รวมเนื้อหาของข้อความในคำขอหากข้อมูลจำเพาะของวิธีการร้องขอ (ส่วน 5.1.1) ไม่อนุญาตให้ส่งเนื้อหาขององค์กรในคำขอ เซิร์ฟเวอร์ควรอ่านและส่งต่อเนื้อความในการร้องขอใด ๆ ; หากวิธีการร้องขอไม่ได้รวมซีแมนทิกส์ที่กำหนดไว้สำหรับเอนทิตีเนื้อหาจากนั้นเนื้อหาของข้อความ SHOULD จะถูกละเว้นเมื่อจัดการคำขอ

และมาตรา 9.7:

เมธอด DELETE ร้องขอให้เซิร์ฟเวอร์ต้นทางลบทรัพยากรที่ระบุโดย Request-URI วิธีนี้อาจถูกแทนที่โดยการแทรกแซงของมนุษย์ (หรือวิธีอื่น ๆ ) บนเซิร์ฟเวอร์ต้นทาง ลูกค้าไม่สามารถรับประกันได้ว่าการดำเนินการได้ดำเนินการแม้ว่ารหัสสถานะที่ส่งคืนจากเซิร์ฟเวอร์ต้นทางบ่งชี้ว่าการดำเนินการเสร็จสมบูรณ์แล้ว อย่างไรก็ตามเซิร์ฟเวอร์ไม่ควรระบุความสำเร็จเว้นแต่ในเวลาที่มีการตอบสนองจะมีความตั้งใจที่จะลบทรัพยากรหรือย้ายไปยังตำแหน่งที่ไม่สามารถเข้าถึงได้

การตอบสนองที่ประสบความสำเร็จควรเป็น 200 (OK) หากการตอบสนองนั้นรวมถึงเอนทิตีที่อธิบายสถานะ 202 (ยอมรับแล้ว) หากการกระทำนั้นยังไม่ได้มีการประกาศใช้หรือ 204 (ไม่มีเนื้อหา) หากการกระทำนั้นมีการตราขึ้นแล้ว นิติบุคคล

หากการร้องขอผ่านแคชและ Request-URI ระบุเอนทิตีแคชในปัจจุบันอย่างน้อยหนึ่งรายการรายการเหล่านั้นควรถูกใช้เป็นค้าง การตอบสนองต่อวิธีนี้ไม่สามารถแคชได้

ดังนั้นจึงไม่ได้รับอนุญาตหรือไม่อนุญาตอย่างชัดเจนและมีโอกาสที่พร็อกซีตลอดทางอาจลบเนื้อหาของข้อความ (แม้ว่ามันควรจะอ่านและส่งต่อ)

— อดัมโรเซนฟิลด์
แหล่งที่มา

19

เพียงแค่หัวขึ้นหากคุณจัดหาเนื้อหาในคำขอ DELETE ของคุณและกำลังใช้ตัวโหลดบาลานซ์ HTTPS ของ Google Cloud ก็จะปฏิเสธคำขอของคุณด้วยข้อผิดพลาด 400 ฉันต่อสู้กับกำแพงและพบว่า Google ไม่ว่าด้วยเหตุผลใดคิดว่าคำขอลบด้วยร่างกายเป็นคำขอที่มีรูปแบบไม่ถูกต้อง

— เบ็นทอด
แหล่งที่มา

1

for whatever reason- เพราะสเป็คพูดอย่างนั้น: P

— Mardoxx

20

สเป็คไม่ได้ "พูดอย่างนั้น" มันแค่บอกว่าร่างกายไม่ได้กำหนดไว้โดยเฉพาะ หากยังไม่ได้กำหนดและคุณต้องการที่จะละเว้นมันเจ๋ง ... ไปข้างหน้าและไม่สนใจมัน แต่การปฏิเสธคำขอโดยทันทีดูเหมือนจะสุดขั้วและไม่จำเป็น

— Ben Fried

1

อย่าพึ่งพาพฤติกรรมที่ไม่ได้กำหนด มันเป็นวิธีปฏิบัติที่ดีที่สุดที่ใช้กันทั่วไป

— ปลิ้น

@Evert มีพฤติกรรมที่ไม่ได้กำหนดอย่างชัดเจน (เช่นคุณเห็นอธิบายในข้อกำหนดของภาษา C เช่น) และมีพฤติกรรมที่ได้รับอนุญาต แต่ก็ไม่ได้อธิบาย การใช้เนื้อหาของข้อความDELETEเป็นสิ่งสุดท้าย

— Alnitak

9

เป็นที่น่าสังเกตว่าข้อกำหนดของ OpenAPI สำหรับเวอร์ชัน 3.0 ได้รับการสนับสนุนสำหรับเมธอด DELETE ที่มีเนื้อความ:

ดูที่นี่และที่นี่สำหรับการอ้างอิง

สิ่งนี้อาจส่งผลต่อการใช้งานเอกสารหรือการใช้ API เหล่านี้ของคุณในอนาคต

— CleverPatrick
แหล่งที่มา

7

ดูเหมือนว่า ElasticSearch จะใช้สิ่งนี้: https://www.elastic.co/guide/en/elasticsearch/reference/5.x/search-request-scroll.html#_clear_scroll_api

ซึ่งหมายความว่า Netty สนับสนุนสิ่งนี้

เช่นเดียวกับที่กล่าวถึงในความคิดเห็นอาจไม่เป็นเช่นนั้นอีกต่อไป

— เซบาสเตียน Lorber
แหล่งที่มา

1

หากคุณใช้ apache http client คุณสามารถสร้าง GET และ DELETE เวอร์ชันของคุณเองได้อย่างง่ายดายโดยการขยาย HttpEntityEnclosingRequestBase และทำให้เมธอด getMethod () ส่งคืน GET หรือ DELETE เราใช้สิ่งนี้เพื่อพูดคุยกับ ElasticSearch

— Jilles van Gurp

2

ลิงค์ตาย - ดีมาก เราต้องการคำตอบจากลิงค์เหล่านั้นมากกว่านี้ - ไม่ใช่

— cottton

3

ตอนนี้เอกสารที่เชื่อมโยงมีเพียงคำขอ POST เท่านั้นไม่มีการลบ อาจจะมีมูลค่าเพิ่มบันทึกคำตอบนี้หรือไม่?

— dshepherd

Elasticsearch ใช้เนื้อหาที่มีคำขอ GET ด้วย

— Nidhin David

7

Roy Fielding ในรายการส่งเมล HTTP ชี้แจงว่าในรายการส่งเมล http https://lists.w3.org/Archives/Public/ietf-http-wg/2020JanMar/0123.htmlและพูดว่า:

GET / DELETE ห้ามมิให้มีผลกระทบใด ๆ ในการประมวลผลหรือตีความคำขอ

ซึ่งหมายความว่าร่างกายต้องไม่ปรับเปลี่ยนพฤติกรรมของเซิร์ฟเวอร์ จากนั้นเขาก็เพิ่ม:

นอกเหนือจากความจำเป็นในการอ่านและทิ้งไบต์ที่ได้รับเพื่อรักษากรอบข้อความ

และในที่สุดเหตุผลที่ไม่ห้ามไม่ให้มีร่างกาย:

เหตุผลเดียวที่เราไม่ห้ามการส่งศพคือเพราะจะนำไปสู่การใช้งานที่ขี้เกียจโดยไม่คิดว่าจะมีการส่งศพ

ดังนั้นในขณะที่ลูกค้าสามารถส่งส่วนของข้อมูลได้เซิร์ฟเวอร์ควรวางและ API ไม่ควรกำหนดความหมายสำหรับส่วนของข้อมูลในคำขอเหล่านั้น

— Roberto Polli
แหล่งที่มา

5

นี้ไม่ได้กำหนดไว้

เพย์โหลดภายในข้อความคำขอลบไม่มีความหมายที่กำหนดไว้ การส่งส่วนของส่วนของข้อมูลบนคำขอ DELETE อาจทำให้การใช้งานที่มีอยู่บางส่วนปฏิเสธคำขอ
https://tools.ietf.org/html/rfc7231#page-29

— ไซม่อนจิน
แหล่งที่มา

โดยเฉพาะRFC 7231 หัวข้อ 4.3.5

— mndrix

3

คำพูดที่ถูกต้องนี้รวมอยู่ในคำตอบก่อนหน้าคำตอบนี้ควรถูกลบ

— Madbreaks

5

การใช้ DELETE กับร่างกายมีความเสี่ยง ... ฉันชอบวิธีการนี้สำหรับการดำเนินการตามรายการมากกว่า REST

ปฏิบัติการปกติ

GET / วัตถุ / รับวัตถุทั้งหมด

GET / object / ID รับวัตถุที่มี ID ที่ระบุ

POST / objects เพิ่มวัตถุใหม่

วาง / object / ID เพิ่มวัตถุที่มี ID ที่ระบุปรับปรุงวัตถุ

DELETE / object / ID ลบวัตถุที่มี ID ที่ระบุ

การกระทำที่กำหนดเองทั้งหมดคือ POST

POST / objects / addList เพิ่มรายการหรืออาร์เรย์ของวัตถุที่รวมอยู่ในเนื้อหา

POST / objects / deleteList ลบรายชื่อของวัตถุที่รวมอยู่ในร่างกาย

POST / objects / customQuery สร้างรายการตามแบบสอบถามที่กำหนดเองในเนื้อหา

หากลูกค้าไม่สนับสนุนการดำเนินการเพิ่มเติมของคุณพวกเขาสามารถทำงานได้ตามปกติ

— Eliezer Garza
แหล่งที่มา

การใช้ a POSTไม่ใช่วิธีที่ดีในการสร้างทรัพยากรใหม่เนื่องจากความหมายของการตอบกลับ POST ไม่ชัดเจนโดยเฉพาะอย่างยิ่งในบริบทของส่วนหัวสถานที่ตั้ง คุณต้องทิ้ง HTTP ไว้เบื้องหลังและสแต็ก RPC ไว้ด้านบน เหมาะสม "ทาง HTTP / REST" คือการสร้างทรัพยากรโดยใช้PUTw / If-None-Match: *ส่วนหัว (หรือ spec'ing วิธีการที่เหมาะสม HTTP ดูMKCOLฯลฯ )

— hnh

4

ฉันไม่คิดว่าคำตอบที่ดีสำหรับโพสต์นี้จะได้รับการโพสต์ถึงแม้ว่าจะมีความคิดเห็นที่ดีมากมายเกี่ยวกับคำตอบที่มีอยู่ ฉันจะยกส่วนสำคัญของความคิดเห็นเหล่านั้นเป็นคำตอบใหม่:

ย่อหน้านี้จาก RFC7231ได้รับการยกมาสองสามครั้งซึ่งรวมกันแล้ว

เพย์โหลดภายในข้อความคำขอลบไม่มีความหมายที่กำหนดไว้ การส่งส่วนของส่วนของข้อมูลบนคำขอ DELETE อาจทำให้การใช้งานที่มีอยู่บางส่วนปฏิเสธคำขอ

สิ่งที่ฉันพลาดจากคำตอบอื่น ๆ คือความหมาย ใช่ได้รับอนุญาตให้รวมเนื้อหาตามDELETEคำขอ แต่ไม่มีความหมายทางความหมาย นี่หมายถึงอะไรจริงๆนั่นคือการออกDELETEคำขอด้วยเนื้อความร้องขอนั้นมีความหมายเทียบเท่ากับไม่รวมเนื้อหาของคำขอ

การรวมเนื้อหาคำขอไม่ควรมีผลกระทบใด ๆ กับคำขอดังนั้นจึงไม่มีประเด็นในการรวมคำขอ

tl; dr: DELETEอนุญาตให้มีการร้องขอด้วยเนื้อหาของคำขอทางเทคนิค แต่ไม่มีประโยชน์ที่จะทำเช่นนั้น

— ปลิ้น
แหล่งที่มา

2

"ไม่มีความหมายเชิงความหมาย" ไม่ได้หมายความว่า "ไม่มีความหมายที่กำหนด" อดีตหมายถึงว่ามันไม่มีความหมายใด ๆ สิ่งหลังหมายถึงเพียงว่า RFC เองไม่ได้ระบุว่าความหมายเหล่านั้นอาจเป็นอะไร (ฉันเขียน RFCs)

— Alnitak

1

กล่าวอีกนัยหนึ่งถ้าผู้ดำเนินการของ API ต้องการกำหนดความหมายบางอย่างสำหรับตัวเองพวกเขาจะสามารถทำเช่นนั้นได้อย่างสมบูรณ์แบบ

— Alnitak

1

@Alitit นี่เป็นการตีความผิดพลาดอย่างแน่นอน ตามคำจำกัดความเนื้อหาคำขอ HTTP ใด ๆนั้นไม่มีซีแมนทิกส์ที่กำหนดไว้ แต่ DELETE และ GET จะถูกเรียกใช้โดยเฉพาะในสเปค นี่คือตัวอย่างจากร่างยังไปได้รับการตีพิมพ์การพูดคุยเกี่ยวกับเรื่องนี้โดยเฉพาะเกี่ยวกับการร้องขอการ GET:

— ปลิ้น

1

ฉันไม่เห็นด้วยกับคุณว่านี่เป็นสิ่งที่ไม่ชัดเจนใน RFC ของที่วางจำหน่ายในปัจจุบัน แต่ถ้าคุณไม่เชื่อฉันฉันจะเชิญคุณให้ถามผู้เขียนหลังจากเจตนาของพวกเขาในการลบและรับ คุณจะพบว่ามันสอดคล้องกับคำตอบของฉัน เช่นเดียวกับคุณฉันมีส่วนร่วมในองค์กรมาตรฐานและฉันไม่ได้เป็นเพียงคนเดียวที่มีความเห็นเกี่ยวกับวิธีการตีความ RFC

— ปลิ้น

2

หากเป็นเช่นนั้นกรณีที่ 7231 เป็นคำพูดที่ไม่ดีและควรพูดว่า คุณหมายถึงร่างใดด้านบน

— Alnitak

3

ในกรณีที่มีผู้ใช้งานในการทดสอบปัญหานี้ไม่ไม่ได้รับการสนับสนุนในระดับสากล

ขณะนี้ฉันกำลังทดสอบกับ Sahi Pro และเห็นได้ชัดว่ามีการเรียก http DELETE เพื่อดึงข้อมูลใด ๆ ของร่างกาย (รายการรหัสขนาดใหญ่เพื่อลบจำนวนมากตามการออกแบบปลายทาง)

ฉันได้รับการติดต่อกับพวกเขาหลายครั้งเช่นเดียวกับที่ส่งในสามชุดที่แยกจากกันของคนร้าย, ภาพ, บันทึกเพื่อให้พวกเขาตรวจสอบและพวกเขายังไม่ได้ยืนยันเรื่องนี้ แพตช์ที่ล้มเหลวและการประชุมที่ไม่ได้รับจากฝ่ายสนับสนุนในภายหลังและฉันยังไม่ได้รับคำตอบที่ชัดเจน

ฉันแน่ใจว่า Sahi ไม่สนับสนุนสิ่งนี้และฉันคิดว่าเครื่องมืออื่น ๆ มากมายตามมาด้วยชุดเครื่องมือ

— ปาร์กเกอร์
แหล่งที่มา

มันถูกนำมาใช้ในรุ่นล่าสุดของ Sahi Pro เนื่องจาก Sahi ใช้จาวาในการโทร HTTP และ Java มีข้อผิดพลาดก่อนเวอร์ชัน 1.8 ซึ่งจะไม่อนุญาตให้ผู้ใช้ทำการร้องขอ DELETE ดังนั้นด้วย Java 1.8 เป็นต้นไปและ Sahi Pro 6.1.1 (ที่จะเปิดตัวเร็ว ๆ นี้) ผู้คนสามารถทำการร้องขอ DELETE กับเนื้อหาใน Sahi ได้

— Vivek V Dwivedi

-1

อาจเป็น URL GitHUb ด้านล่างนี้จะช่วยคุณในการรับคำตอบ ที่จริงแล้วแอปพลิเคชันเซิร์ฟเวอร์เช่น Tomcat เว็บล็อกปฏิเสธการเรียก HTTP.DELETE พร้อมคำขอเพย์โหลด ดังนั้นการรักษาทุกสิ่งไว้ในใจฉันได้เพิ่มตัวอย่างใน GitHub โปรดดูที่

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

— Ashish
แหล่งที่มา

-1

ฉันสามารถใช้งานการดำเนินการ DELETE ด้วยเนื้อความคำขอ ฉันใช้เกตเวย์ AWS แลมบ์ดาและ AWS API และใช้ภาษาโก

— Dattatray
แหล่งที่มา

3

พวกเขากำลังพูดถึงมาตรฐานไม่ใช่ความสามารถ คุณสามารถขอ GET กับร่างกายได้ซึ่งไม่ดี

— ReZa