ข้อแตกต่างระหว่าง POST และคำขอ PUT HTTP คืออะไร

พวกเขาทั้งคู่ดูเหมือนกำลังส่งข้อมูลไปยังเซิร์ฟเวอร์ภายในร่างกายดังนั้นอะไรที่ทำให้พวกเขาแตกต่างกัน

HTTP PUT:

PUT วางไฟล์หรือทรัพยากรที่ URI ที่เฉพาะเจาะจงและตรงที่ URI นั้น หากมีไฟล์หรือทรัพยากรอยู่ที่ URI นั้นแล้ว PUT จะแทนที่ไฟล์หรือทรัพยากรนั้น หากไม่มีไฟล์หรือทรัพยากรอยู่ที่นั่น PUT จะสร้างขึ้นมาใหม่ PUT เป็นidempotentแต่การตอบกลับ PUT ที่ขัดแย้งกันไม่สามารถแคชได้

HTTP 1.1 ตำแหน่ง RFC สำหรับ PUT

HTTP POST:

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

HTTP RFC อย่างเป็นทางการระบุ POST เป็น:

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

HTTP 1.1 ตำแหน่ง RFC สำหรับ POST

ความแตกต่างระหว่าง POST และ PUT:

RFC เองนั้นอธิบายความแตกต่างที่สำคัญ:

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

ยิ่งไปกว่านั้นRFC 7231 ตอนที่ 4.3.4 PUTระบุด้วย

4.3.4 PUT

วิธี PUT ร้องขอให้สถานะของทรัพยากรเป้าหมายเป็น createdหรือreplacedด้วยสถานะที่กำหนดโดยการแสดงที่ล้อมรอบในเพย์โหลดข้อความคำขอ

การใช้วิธีการที่ถูกต้องไม่เกี่ยวข้องกัน:

ข้อดีอย่างหนึ่งของREST ROAกับ SOAP คือเมื่อใช้ HTTP REST ROA จะส่งเสริมการใช้คำกริยา HTTP / วิธีที่เหมาะสม ตัวอย่างเช่นคุณจะใช้ PUT เฉพาะเมื่อคุณต้องการสร้างทรัพยากรในตำแหน่งที่แน่นอน และคุณจะไม่ใช้ GET เพื่อสร้างหรือปรับเปลี่ยนทรัพยากร

ความหมายเท่านั้น

HTTP PUTควรจะยอมรับเนื้อหาของคำขอจากนั้นเก็บไว้ที่ทรัพยากรที่ระบุโดย URI

HTTP POSTเป็นแบบทั่วไปมากขึ้น มันควรจะเริ่มการกระทำบนเซิร์ฟเวอร์ การกระทำนั้นอาจเป็นการจัดเก็บเนื้อหาคำขอไว้ที่ทรัพยากรที่ระบุโดย URI หรืออาจเป็น URI อื่นหรืออาจเป็นการกระทำที่แตกต่างกัน

PUT เปรียบเสมือนการอัปโหลดไฟล์ การใส่ URI นั้นส่งผลกระทบกับ URI นั้น โพสต์ถึง URI อาจมีผลกระทบใด ๆ เลย

ในการให้ตัวอย่างของแหล่งข้อมูลสไตล์ REST:

"POST / หนังสือ" ที่มีข้อมูลหนังสือมากมายอาจสร้างหนังสือเล่มใหม่และตอบกลับด้วย URL ใหม่ที่ระบุว่าหนังสือเล่มนี้: "/ books / 5"

"PUT / books / 5" จะต้องสร้างหนังสือใหม่ด้วย id 5 หรือแทนที่หนังสือที่มีอยู่ด้วย ID 5

ในรูปแบบที่ไม่ใช่ทรัพยากร POST สามารถใช้กับทุกสิ่งที่มีผลข้างเคียง ข้อแตกต่างอีกอย่างหนึ่งคือ PUT ควรเป็น idempotent - PUT หลาย ๆ อันของข้อมูลเดียวกันกับ URL เดียวกันควรจะดีถ้าโพสต์หลายรายการอาจสร้างวัตถุหลายรายการหรืออะไรก็ตามที่เป็นการกระทำ POST ของคุณ

1. GET : ดึงข้อมูลจากเซิร์ฟเวอร์ ไม่ควรมีผลกระทบอื่น
2. POST : ส่งข้อมูลไปยังเซิร์ฟเวอร์เพื่อสร้างเอนทิตีใหม่ มักใช้เมื่ออัปโหลดไฟล์หรือส่งแบบฟอร์มบนเว็บ
3. PUT : คุ้นเคยกับ POST แต่ใช้เพื่อแทนที่เอนทิตีที่มีอยู่
4. PATCH : คล้ายกับ PUT แต่ใช้เพื่ออัปเดตเฉพาะบางฟิลด์ภายในเอนทิตีที่มีอยู่
5. DELETE : ลบข้อมูลออกจากเซิร์ฟเวอร์
6. TRACE : เป็นวิธีทดสอบว่าเซิร์ฟเวอร์ได้รับอะไร เพียงแค่ส่งคืนสิ่งที่ถูกส่ง
7. ตัวเลือก : อนุญาตให้ลูกค้ารับข้อมูลเกี่ยวกับวิธีการร้องขอที่บริการสนับสนุน ส่วนหัวการตอบสนองที่เกี่ยวข้องคืออนุญาตด้วยวิธีการที่รองรับ นอกจากนี้ยังใช้ใน CORS เป็นคำขอ preflight แจ้งเซิร์ฟเวอร์เกี่ยวกับวิธีการร้องขอจริงและถามเกี่ยวกับส่วนหัวที่กำหนด
8. HEAD : ส่งคืนเฉพาะส่วนหัวการตอบกลับ
9. เชื่อมต่อ : ใช้โดยเบราว์เซอร์เมื่อรู้ว่ามันพูดกับพร็อกซีและ URI สุดท้ายนั้นเริ่มต้นด้วย https: // จุดประสงค์ของการเชื่อมต่อคือการอนุญาตเซสชัน TLS ที่เข้ารหัสแบบครบวงจรดังนั้นข้อมูลจึงไม่สามารถอ่านไปยังพร็อกซี

PUT มีความหมายว่าเป็นวิธีการในการ "อัปโหลด" ข้อมูลไปยัง URI เฉพาะหรือเขียนทับสิ่งที่มีอยู่แล้วใน URI นั้น

POST ตรงกันข้ามเป็นวิธีการส่งข้อมูลที่เกี่ยวข้องกับ URI ที่กำหนด

อ้างถึงHTTP RFC

เท่าที่ฉันรู้ PUT ส่วนใหญ่จะใช้สำหรับการปรับปรุงระเบียน

1. POST - เพื่อสร้างเอกสารหรือทรัพยากรอื่น ๆ

2. วาง - เพื่อปรับปรุงเอกสารที่สร้างขึ้นหรือทรัพยากรอื่น ๆ

แต่เพื่อให้ชัดเจนใน PUT นั้นมักจะ 'แทนที่' บันทึกที่มีอยู่ถ้ามีและสร้างถ้ามันไม่ได้มี ..

คนอื่น ๆ โพสต์คำตอบที่ยอดเยี่ยมแล้วฉันแค่อยากจะเพิ่มสิ่งนั้นกับภาษากรอบงานและใช้กรณีที่คุณจะจัดการกับ POST บ่อยกว่า PUT จนถึงจุดที่ PUT, DELETE และอื่น ๆ นั้นเป็นคำถามที่ไม่สำคัญ

โปรดดู: http://zacharyvoase.com/2009/07/03/http-post-put-diff/

ฉันรู้สึกรำคาญเมื่อเร็ว ๆ นี้จากความเข้าใจผิดที่เป็นที่นิยมของนักพัฒนาเว็บที่ใช้ POST เพื่อสร้างทรัพยากรและ PUT ใช้เพื่ออัปเดต / เปลี่ยนแปลง

หากคุณดูที่หน้า 55 ของ RFC 2616 (“ Hypertext Transfer Protocol - HTTP / 1.1”), มาตรา 9.6 (“ PUT”) คุณจะเห็นว่า PUT นั้นมีไว้เพื่ออะไร:

วิธี PUT ร้องขอให้เก็บเอนทิตีที่ถูกล้อมไว้ภายใต้ Request-URI ที่ให้มา

นอกจากนี้ยังมีย่อหน้าที่สะดวกในการอธิบายความแตกต่างระหว่าง POST และ PUT:

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

ไม่ได้พูดถึงอะไรเกี่ยวกับความแตกต่างระหว่างการอัพเดท / การสร้างเพราะมันไม่ใช่สิ่งที่มันเกี่ยวข้อง มันเกี่ยวกับความแตกต่างระหว่างสิ่งนี้:

obj.set_attribute(value) # A POST request.

และนี่:

obj.attribute = value # A PUT request.

ดังนั้นโปรดหยุดการแพร่กระจายของความเข้าใจผิดที่เป็นที่นิยมนี้ อ่าน RFC ของคุณ

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

REST ขอให้ผู้พัฒนาใช้วิธีการ HTTP อย่างชัดเจนและในลักษณะที่สอดคล้องกับข้อกำหนดของโปรโตคอล หลักการออกแบบ REST พื้นฐานนี้สร้างการแม็พแบบหนึ่งต่อหนึ่งระหว่างการดำเนินการสร้างอ่านอัปเดตและลบ (CRUD) และวิธี HTTP ตามแผนที่นี้:

•ในการสร้างทรัพยากรบนเซิร์ฟเวอร์ให้ใช้ POST

•เพื่อดึงทรัพยากรใช้ GET

•ในการเปลี่ยนสถานะของทรัพยากรหรืออัพเดทให้ใช้ PUT

•ในการลบหรือลบทรัพยากรให้ใช้ DELETE

ข้อมูลเพิ่มเติม: บริการเว็บสงบ: พื้นฐานจาก IBM

มันควรจะตรงไปตรงมาเมื่อใช้อย่างใดอย่างหนึ่ง แต่คำที่ซับซ้อนเป็นแหล่งของความสับสนสำหรับเราหลายคน

ควรใช้เมื่อใด:

• ใช้PUTเมื่อคุณต้องการแก้ไขทรัพยากรเอกพจน์ที่เป็นส่วนหนึ่งของการรวบรวมทรัพยากรอยู่แล้ว PUTแทนที่ทรัพยากรทั้งหมด ตัวอย่าง:PUT /resources/:resourceId

  Sidenote:ใช้PATCHหากคุณต้องการอัปเดตส่วนของทรัพยากร

• ใช้POSTเมื่อคุณต้องการเพิ่มทรัพยากรลูกภายใต้ชุดของทรัพยากร
  ตัวอย่าง:POST => /resources

โดยทั่วไป:

• โดยทั่วไปในทางปฏิบัติมักจะใช้PUTสำหรับการดำเนินการปรับปรุง
• ใช้POSTสำหรับการดำเนินการสร้างเสมอ

ตัวอย่าง:

GET / company / reports => รับ รายงานทั้งหมด
GET / บริษัท / reports / {id} => รับข้อมูลรายงานที่ระบุโดย "id"
POST / company / reports => สร้างรายงานใหม่
PUT / company / reports / {id} => อัปเดต ข้อมูลรายงานที่ระบุโดย "id"
PATCH / บริษัท / reports / {id} => อัปเดตส่วนหนึ่งของข้อมูลรายงานที่ระบุโดย "id"
DELETE / บริษัท / รายงาน / {id} => ลบรายงานด้วย "id"

ความแตกต่างระหว่าง POST และ PUT คือ PUT นั้น idempotent นั่นหมายความว่าการเรียกใช้คำขอ PUT เดียวกันหลายครั้งจะให้ผลลัพธ์เดียวกันเสมอ (นั่นคือไม่มีผลข้างเคียง) ในขณะที่ในทางกลับกันการเรียกร้องคำขอ POST ซ้ำ ๆ อาจมี ( เพิ่มเติม) ผลข้างเคียงของการสร้างทรัพยากรเดียวกันหลายครั้ง

GET : คำขอที่ใช้ GET ดึงข้อมูลเท่านั้นนั่นคือมันร้องขอการเป็นตัวแทนของทรัพยากรที่ระบุ

POST: มันจะส่งข้อมูลไปยังเซิร์ฟเวอร์เพื่อสร้างทรัพยากร ชนิดของเนื้อความของคำร้องขอถูกระบุโดยส่วนหัว Content-Type มักทำให้เกิดการเปลี่ยนแปลงสถานะหรือผลข้างเคียงบนเซิร์ฟเวอร์

PUT : สร้างรีซอร์สใหม่หรือแทนที่การแสดงของรีซอร์สเป้าหมายด้วย payload คำร้องขอ

PATCH : มันถูกใช้เพื่อปรับใช้บางส่วนกับทรัพยากร

DELETE : ลบทรัพยากรที่ระบุ

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

OPTIONS : ใช้เพื่ออธิบายตัวเลือกการสื่อสารสำหรับทรัพยากรเป้าหมายลูกค้าสามารถระบุ URL สำหรับวิธี OPTIONS หรือเครื่องหมายดอกจัน (*) เพื่ออ้างถึงเซิร์ฟเวอร์ทั้งหมด

HEAD : มันขอการตอบสนองเหมือนกับคำขอ GET แต่ไม่มีเนื้อความการตอบสนอง

CONNECT : มันสร้างอุโมงค์ไปยังเซิร์ฟเวอร์ที่ระบุโดยทรัพยากรเป้าหมายสามารถใช้ในการเข้าถึงเว็บไซต์ที่ใช้ SSL (HTTPS)

การใช้งานส่วนที่เหลือ

POST ใช้ในการสร้างทรัพยากรใหม่จากนั้นส่งคืนทรัพยากร URI

EX 
      REQUEST : POST ..../books
        {
        "book":"booName",
        "author":"authorName"
        }

สายนี้อาจสร้างหนังสือใหม่และส่งคืนหนังสือเล่มนั้น URI

Response ...THE-NEW-RESOURCE-URI/books/5

PUT ใช้เพื่อแทนที่ทรัพยากรหากทรัพยากรนั้นมีอยู่แล้วเพียงแค่อัปเดต แต่หากทรัพยากรนั้นไม่มีอยู่ให้สร้างขึ้นใหม่

REQUEST : PUT ..../books/5
{
"book":"booName",
"author":"authorName"
}

เมื่อPUTเราทราบตัวระบุทรัพยากรแล้ว แต่POSTจะส่งคืนตัวระบุทรัพยากรใหม่

การใช้งานที่ไม่ใช่ส่วนที่เหลือ

POST ใช้เพื่อเริ่มต้นการกระทำที่ฝั่งเซิร์ฟเวอร์การกระทำนี้อาจหรือไม่อาจสร้างทรัพยากรได้ แต่การกระทำนี้จะมีผลข้างเคียงอยู่เสมอมันจะเปลี่ยนบางสิ่งบางอย่างบนเซิร์ฟเวอร์

PUT ใช้เพื่อวางหรือแทนที่เนื้อหาที่แท้จริงที่ URL ที่ระบุ

ความแตกต่างในทั้งสไตล์ REST-ful และไม่ใช่ REST-ful

POST is Non-Idempotent Operation: มันจะทำให้เกิดการเปลี่ยนแปลงบางอย่างหากดำเนินการหลายครั้งด้วยคำขอเดียวกัน

PUT คือการทำงานของ Idempotent: มันจะไม่มีผลข้างเคียงหากดำเนินการหลายครั้งด้วยการร้องขอเดียวกัน

เป็นเรื่องที่ควรค่าแก่การกล่าวถึงซึ่งPOSTอาจมีการโจมตี Cross-Site Request Forgery (CSRF) บางอย่างที่PUTไม่ได้เกิดขึ้น

CSRF ด้านล่างนี้เป็นไปไม่ได้กับPUTattackersite.comเมื่อผู้เข้าชมเหยื่อ

ผลของการโจมตีคือการที่เหยื่อไม่ได้ตั้งใจลบผู้ใช้เพียงเพราะมัน (เหยื่อ) คือการเข้าสู่ระบบในขณะที่adminบนtarget.site.comก่อนที่จะเยี่ยมชมattackersite.com:

คำขอปกติ (ส่งคุกกี้แล้ว): ( PUTไม่ใช่ค่าแอตทริบิวต์ที่รองรับ)

รหัสบนattackersite.com:

<form id="myform" method="post" action="http://target.site.com/deleteUser" >
    <input type="hidden" name="userId" value="5">
</form>
<script>document.createElement('form').submit.call(document.getElementById('myform'));</script>

คำขอ XHR (คุกกี้ถูกส่ง): ( PUTจะเรียกใช้คำขอ preflight ซึ่งการตอบสนองจะป้องกันไม่ให้เบราว์เซอร์ร้องขอdeleteUserหน้า)

var xhr = new XMLHttpRequest();
xhr.open("POST", "http://target.site.com/deleteUser");
xhr.withCredentials=true;
xhr.send(["userId=5"]);

ในคำง่าย ๆ คุณสามารถพูดได้:

1.HTTP Get: ใช้เพื่อรับหนึ่งไอเท็มหรือมากกว่า

2.HTTP โพสต์: มันถูกใช้เพื่อสร้างรายการ

3.HTTP Put: มันถูกใช้เพื่ออัปเดตรายการ

4.HTTP Patch: มันถูกใช้เพื่ออัพเดทบางส่วนของรายการ

5.HTTP Delete: มันถูกใช้เพื่อลบรายการ

จริงๆแล้วไม่มีความแตกต่างจากชื่อของพวกเขา จริงๆแล้วมีความแตกต่างพื้นฐานระหว่าง GET และอื่น ๆ ด้วยเมธอด "GET" -Request คุณจะส่งข้อมูลใน url-address-line ซึ่งคั่นด้วยเครื่องหมายคำถามเป็นอันดับแรกจากนั้นด้วยเครื่องหมาย &

แต่ด้วยวิธีการ "POST" - คำขอคุณไม่สามารถส่งผ่านข้อมูลผ่าน url ได้ แต่คุณต้องส่งข้อมูลเป็นวัตถุใน "body" ที่เรียกว่าของคำขอ ที่ฝั่งเซิร์ฟเวอร์คุณต้องอ่านเนื้อหาของเนื้อหาที่ได้รับเพื่อรับข้อมูลที่ส่ง แต่มีอีกด้านหนึ่งที่ไม่มีความเป็นไปได้ที่จะส่งเนื้อหาในร่างกายเมื่อคุณส่ง "รับ" - ขอ

การอ้างสิทธิ์ว่า "GET" มีไว้สำหรับรับข้อมูลเท่านั้นและ "POST" สำหรับการโพสต์ข้อมูลนั้นผิดอย่างแน่นอน ไม่มีใครสามารถป้องกันคุณจากการสร้างเนื้อหาใหม่การลบเนื้อหาที่มีอยู่แก้ไขเนื้อหาที่มีอยู่หรือทำสิ่งใดก็ตามในแบ็กเอนด์ตามข้อมูลที่ส่งโดยคำขอ "GET" หรือตามคำขอ "POST" และไม่มีใครสามารถป้องกันคุณให้เขียนโค้ดแบ็กเอนด์ด้วยวิธีใดวิธีหนึ่งว่า "POST" - ตามคำขอลูกค้าจะขอข้อมูลบางอย่าง

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

มีเพียงสองวิธีพื้นฐานเหล่านี้ รับและโพสต์ แต่เป็นโครงสร้างของพวกเขาซึ่งทำให้พวกเขาแตกต่างและไม่ใช่สิ่งที่คุณรหัสในแบ็กเอนด์ ในแบ็กเอนด์คุณสามารถโค้ดสิ่งที่คุณต้องการด้วยข้อมูลที่ได้รับ แต่ด้วย "โพสต์" - คำขอคุณต้องส่ง / ดึงข้อมูลในเนื้อหาและไม่อยู่ใน url-addressline และด้วยคำขอ "GET" คุณจะต้องส่ง / ดึงข้อมูลใน url-addressline และไม่อยู่ใน ร่างกาย. นั่นคือทั้งหมดที่

วิธีการอื่น ๆ ทั้งหมดเช่น "PUT", "DELETE" และอื่น ๆ พวกเขามีโครงสร้างเดียวกับ "POST"

ส่วนใหญ่จะใช้วิธีการ POST หากคุณต้องการซ่อนเนื้อหาบ้างเพราะสิ่งที่คุณเขียนใน url-addressline สิ่งนี้จะถูกบันทึกไว้ในแคชและ GET-Method นั้นเหมือนกับการเขียน url-addressline ด้วยข้อมูล ดังนั้นหากคุณต้องการส่งข้อมูลที่ละเอียดอ่อนซึ่งไม่จำเป็นต้องเป็นชื่อผู้ใช้และรหัสผ่านเสมอไปตัวอย่างเช่นรหัสหรือแฮชบางตัวซึ่งคุณไม่ต้องการให้แสดงใน url-address-line คุณควรใช้วิธีการ POST .

ความยาวของ URL-Addressline นั้น จำกัด อยู่ที่ 1024 สัญลักษณ์ในขณะที่ "POST" - วิธีการนั้นไม่ได้ถูก จำกัด ดังนั้นหากคุณมีข้อมูลจำนวนมากขึ้นคุณอาจไม่สามารถส่งโดยใช้ GET-Request ได้ แต่คุณจะต้องใช้ POST-Request ดังนั้นนี่เป็นอีกจุดบวกสำหรับคำขอ POST

แต่การจัดการกับคำขอ GET นั้นง่ายกว่าเมื่อคุณไม่มีข้อความที่ซับซ้อนในการส่ง มิฉะนั้นและนี่คืออีกจุดบวกสำหรับวิธีการ POST นั่นคือด้วยวิธีการ GET คุณจะต้องเข้ารหัสข้อความเพื่อที่จะสามารถส่งสัญลักษณ์บางอย่างภายในข้อความหรือช่องว่าง แต่ด้วยวิธีการโพสต์คุณไม่มีข้อ จำกัด และเนื้อหาของคุณไม่จำเป็นต้องเปลี่ยนหรือจัดการในทางใดทางหนึ่ง

ทั้ง PUT และ POST เป็นวิธีการพักผ่อน

วาง - ถ้าเราทำคำขอเดียวกันสองครั้งโดยใช้ PUT โดยใช้พารามิเตอร์เดียวกันทั้งสองครั้งคำขอที่สองจะไม่มีผลใด ๆ นี่คือเหตุผลที่ PUT ถูกใช้โดยทั่วไปสำหรับสถานการณ์การอัพเดตการเรียกการอัพเดตมากกว่าหนึ่งครั้งด้วยพารามิเตอร์เดียวกันไม่ได้ทำอะไรมากไปกว่าการโทรเริ่มต้นดังนั้น PUT จึงเป็น idempotent

POST ไม่ใช่ idempotent ตัวอย่างเช่น Create จะสร้างสองรายการแยกกันในเป้าหมายดังนั้นจึงไม่ใช่ idempotent ดังนั้น CREATE จึงใช้กันอย่างแพร่หลายใน POST

การโทรเดียวกันโดยใช้ POST ด้วยพารามิเตอร์เดียวกันในแต่ละครั้งจะทำให้เกิดสองสิ่งที่แตกต่างกันดังนั้นเหตุใดจึงใช้ POST โดยทั่วไปสำหรับสถานการณ์