Câu trả lời:
PUT HTTP:
PUT đặt một tệp hoặc tài nguyên tại một URI cụ thể và chính xác tại URI đó. Nếu đã có tệp hoặc tài nguyên tại URI đó, PUT sẽ thay thế tệp hoặc tài nguyên đó. Nếu không có tệp hoặc tài nguyên ở đó, PUT tạo một tài nguyên. PUT là idempotent , nhưng nghịch lý PUT không thể lưu trữ được.
BÀI ĐĂNG HTTP:
POST gửi dữ liệu đến một URI cụ thể và hy vọng tài nguyên tại URI đó sẽ xử lý yêu cầu. Máy chủ web tại thời điểm này có thể xác định phải làm gì với dữ liệu trong ngữ cảnh của tài nguyên đã chỉ định. Phương thức POST không phải là idempotent , tuy nhiên các phản hồi POST có thể được lưu trong bộ nhớ cache miễn là máy chủ đặt các tiêu đề Kiểm soát bộ đệm và hết hạn thích hợp.
HTTP RFC chính thức chỉ định POST là:
Sự khác biệt giữa POST và PUT:
Bản thân RFC giải thích sự khác biệt cốt lõi:
Sự khác biệt cơ bản giữa các yêu cầu POST và PUT được phản ánh theo nghĩa khác nhau của URI yêu cầu. URI trong yêu cầu POST xác định tài nguyên sẽ xử lý thực thể kèm theo. Tài nguyên đó có thể là một quá trình chấp nhận dữ liệu, một cổng vào một số giao thức khác hoặc một thực thể riêng biệt chấp nhận các chú thích. Ngược lại, URI trong yêu cầu PUT xác định thực thể kèm theo yêu cầu - tác nhân người dùng biết URI dự định là gì và máy chủ KHÔNG cố gắng áp dụng yêu cầu cho một số tài nguyên khác. Nếu máy chủ mong muốn yêu cầu được áp dụng cho một URI khác, thì PHẢI gửi phản hồi 301 (Đã di chuyển vĩnh viễn); tác nhân người dùng CÓ THỂ đưa ra quyết định của riêng mình về việc có chuyển hướng yêu cầu hay không.
Ngoài ra, và chính xác hơn một chút, RFC 7231 Mục 4.3.4 trạng thái PUT (nhấn mạnh thêm),
4.3.4. ĐẶT
Phương thức PUT yêu cầu trạng thái của tài nguyên đích phải
createdhoặcreplacedvới trạng thái được xác định bởi biểu diễn kèm theo trong tải trọng thông báo yêu cầu.
Sử dụng đúng phương pháp, không liên quan qua một bên:
Một lợi ích của REST ROA so với SOAP là khi sử dụng HTTP REST ROA, nó khuyến khích việc sử dụng đúng các động từ / phương thức HTTP. Vì vậy, ví dụ bạn sẽ chỉ sử dụng PUT khi bạn muốn tạo tài nguyên tại vị trí chính xác đó. Và bạn sẽ không bao giờ sử dụng GET để tạo hoặc sửa đổi tài nguyên.
If the Request-URI does not point to an existing resource [...] the origin server *can* create the resource with that URI. Vì vậy, việc triển khai PUT từ chối tạo tài nguyên nếu không có mặt sẽ là chính xác, phải không? Nếu vậy, điều này có xảy ra trong thực tế? Hoặc triển khai cũng thường tạo trên PUT?
Chỉ có ngữ nghĩa.
Một HTTP PUTđược cho là chấp nhận phần thân của yêu cầu và sau đó lưu trữ nó tại tài nguyên được xác định bởi URI.
Một HTTP POSTlà tổng quát hơn. Nó được cho là bắt đầu một hành động trên máy chủ. Hành động đó có thể là lưu trữ phần thân yêu cầu tại tài nguyên được xác định bởi URI hoặc nó có thể là một URI khác hoặc nó có thể là một hành động khác.
PUT giống như một tập tin tải lên. Việc đặt vào một URI ảnh hưởng chính xác đến URI đó. POST cho URI có thể có bất kỳ ảnh hưởng nào.
Để đưa ra ví dụ về tài nguyên kiểu REST:
"POST / sách" với một loạt thông tin sách có thể tạo ra một cuốn sách mới và phản hồi với URL mới xác định cuốn sách đó: "/ Books / 5".
"PUT / sách / 5" sẽ phải tạo một cuốn sách mới với id là 5 hoặc thay thế cuốn sách hiện tại bằng ID 5.
Trong kiểu phi tài nguyên, POST có thể được sử dụng cho bất kỳ thứ gì có tác dụng phụ. Một điểm khác biệt nữa là PUT phải là idempotent - nhiều PUT của cùng một dữ liệu cho cùng một URL sẽ ổn, vì nhiều POST có thể tạo ra nhiều đối tượng hoặc bất cứ điều gì đó là hành động POST của bạn.
PUT có nghĩa là một phương pháp để "tải lên" nội dung lên một URI cụ thể hoặc ghi đè lên những gì đã có trong URI đó.
POST, mặt khác, là một cách gửi dữ liệu LIÊN QUAN đến một URI nhất định.
Tham khảo RFC HTTP
Theo tôi biết, PUT chủ yếu được sử dụng để cập nhật các hồ sơ.
POST - Để tạo tài liệu hoặc bất kỳ tài nguyên nào khác
PUT - Để cập nhật tài liệu đã tạo hoặc bất kỳ tài nguyên nào khác.
Nhưng để rõ ràng rằng PUT thường 'Thay thế' bản ghi hiện có nếu nó ở đó và tạo nếu nó không ở đó ..
Những người khác đã đăng câu trả lời tuyệt vời, tôi chỉ muốn thêm rằng với hầu hết các ngôn ngữ, khung và trường hợp sử dụng, bạn sẽ xử lý POST nhiều, thường xuyên hơn PUT. Đến mức PUT, DELETE, v.v ... về cơ bản là những câu hỏi nhỏ.
Vui lòng xem: http://zacharyvoase.com/2009/07/03/http-post-put-diff/
Gần đây tôi đã trở nên khá khó chịu bởi một quan niệm sai lầm phổ biến của các nhà phát triển web rằng POST được sử dụng để tạo tài nguyên và PUT được sử dụng để cập nhật / thay đổi.
Nếu bạn xem trang 55 của RFC 2616 (Giao thức truyền siêu văn bản - HTTP / 1.1,), Phần 9.6 (Nhật ký PUT), bạn sẽ thấy PUT thực sự dùng để làm gì:
Phương thức PUT yêu cầu thực thể kèm theo được lưu trữ theo URI yêu cầu được cung cấp.
Ngoài ra còn có một đoạn tiện dụng để giải thích sự khác biệt giữa POST và PUT:
Sự khác biệt cơ bản giữa các yêu cầu POST và PUT được phản ánh theo nghĩa khác nhau của URI yêu cầu. URI trong yêu cầu POST xác định tài nguyên sẽ xử lý thực thể kèm theo. Tài nguyên đó có thể là một quá trình chấp nhận dữ liệu, một cổng vào một số giao thức khác hoặc một thực thể riêng biệt chấp nhận các chú thích. Ngược lại, URI trong yêu cầu PUT xác định thực thể kèm theo yêu cầu - tác nhân người dùng biết URI được dự định là gì và máy chủ KHÔNG cố gắng áp dụng yêu cầu cho một số tài nguyên khác.
Nó không đề cập bất cứ điều gì về sự khác biệt giữa cập nhật / tạo, bởi vì đó không phải là những gì nó nói về. Đó là về sự khác biệt giữa điều này:
obj.set_attribute(value) # A POST request.
Và điều này:
obj.attribute = value # A PUT request.
Vì vậy, xin vui lòng, ngăn chặn sự lây lan của quan niệm sai lầm phổ biến này. Đọc RFC của bạn.
POST được coi là một cái gì đó của một phương thức loại nhà máy. Bạn bao gồm dữ liệu với nó để tạo ra những gì bạn muốn và bất cứ điều gì ở đầu bên kia đều biết phải làm gì với nó. PUT được sử dụng để cập nhật dữ liệu hiện có tại một URL nhất định hoặc để tạo một cái gì đó mới khi bạn biết URI sẽ ra sao và nó không tồn tại (trái ngược với POST sẽ tạo ra thứ gì đó và trả lại URL cho nếu cần thiết).
REST yêu cầu các nhà phát triển sử dụng các phương thức HTTP một cách rõ ràng và theo cách phù hợp với định nghĩa giao thức. Nguyên tắc thiết kế REST cơ bản này thiết lập ánh xạ một-một giữa các hoạt động tạo, đọc, cập nhật và xóa (CRUD) và các phương thức HTTP. Theo bản đồ này:
• Để tạo tài nguyên trên máy chủ, hãy sử dụng POST.
• Để lấy tài nguyên, sử dụng GET.
• Để thay đổi trạng thái của tài nguyên hoặc cập nhật tài nguyên, hãy sử dụng PUT.
• Để xóa hoặc xóa tài nguyên, hãy sử dụng XÓA.
Thông tin thêm: Các dịch vụ Web RESTful: Những điều cơ bản từ IBM
Nó sẽ khá đơn giản khi sử dụng cái này hay cái kia, nhưng những từ phức tạp là một nguồn gây nhầm lẫn cho nhiều người trong chúng ta.
Sử dụng PUTkhi bạn muốn sửa đổi một tài nguyên số ít đã là một phần của bộ sưu tập tài nguyên. PUTthay thế toàn bộ tài nguyên Thí dụ:PUT /resources/:resourceId
Sidenote: Sử dụng PATCHnếu bạn muốn cập nhật một phần tài nguyên.
POSTkhi bạn muốn thêm tài nguyên con trong bộ sưu tập tài nguyên. POST => /resourcesPUTcho các hoạt động CẬP NHẬT .POSTcho các hoạt động TẠO .GET / company / báo cáo => Nhận tất cả các báo cáo
GET / công ty / báo cáo / {id} => Nhận thông tin báo cáo được xác định bởi "id"
POST / công ty / báo cáo => Tạo báo cáo
PUT / công ty / báo cáo mới / {id} => Cập nhật thông tin báo cáo được xác định bởi "id"
PATCH / company / báo cáo / {id} => Cập nhật một phần thông tin báo cáo được xác định bởi "id"
DELETE / company / báo cáo / {id} => Xóa báo cáo theo "id"
Sự khác biệt giữa POST và PUT là PUT là idempotent, điều đó có nghĩa là, việc gọi cùng một yêu cầu PUT nhiều lần sẽ luôn tạo ra cùng một kết quả (điều đó không có tác dụng phụ), mặt khác, việc gọi một yêu cầu POST liên tục có thể có ( bổ sung) tác dụng phụ của việc tạo cùng một tài nguyên nhiều lần.
GET : Yêu cầu sử dụng GET chỉ lấy dữ liệu, nghĩa là nó yêu cầu đại diện cho tài nguyên đã chỉ định
POST: Nó gửi dữ liệu đến máy chủ để tạo tài nguyên. Loại phần thân của yêu cầu được biểu thị bằng tiêu đề Kiểu nội dung. Nó thường gây ra thay đổi trạng thái hoặc tác dụng phụ trên máy chủ
PUT : Tạo tài nguyên mới hoặc thay thế một đại diện của tài nguyên đích bằng tải trọng yêu cầu
PATCH : Nó được sử dụng để áp dụng sửa đổi một phần cho tài nguyên
DELETE : Nó xóa tài nguyên đã chỉ định
TRACE : Nó thực hiện kiểm tra vòng lặp thông báo dọc theo đường dẫn đến tài nguyên đích, cung cấp một cơ chế gỡ lỗi hữu ích
OPTIONS : Nó được sử dụng để mô tả các tùy chọn giao tiếp cho tài nguyên đích, khách hàng có thể chỉ định URL cho phương thức TÙY CHỌN hoặc dấu hoa thị (*) để chỉ toàn bộ máy chủ.
HEAD : Nó yêu cầu phản hồi giống với yêu cầu GET, nhưng không có phần phản hồi
CONNECT : Nó thiết lập một đường hầm đến máy chủ được xác định bởi tài nguyên đích, có thể được sử dụng để truy cập các trang web sử dụng SSL (HTTPS)
Sử dụng REST-Ful
POST được sử dụng để tạo tài nguyên mới và sau đó trả về tài nguyên URI
EX
REQUEST : POST ..../books
{
"book":"booName",
"author":"authorName"
}
Cuộc gọi này có thể tạo ra một cuốn sách mới và trả lại cuốn sách đó URI
Response ...THE-NEW-RESOURCE-URI/books/5
PUT được sử dụng để thay thế một tài nguyên, nếu tài nguyên đó tồn tại thì chỉ cần cập nhật nó, nhưng nếu tài nguyên đó không tồn tại thì hãy tạo nó,
REQUEST : PUT ..../books/5
{
"book":"booName",
"author":"authorName"
}
Với PUTchúng tôi biết định danh tài nguyên, nhưng POSTsẽ trả về định danh tài nguyên mới
Sử dụng phi REST-Ful
POST được sử dụng để bắt đầu một hành động ở phía máy chủ, hành động này có thể hoặc không thể tạo tài nguyên, nhưng hành động này sẽ có tác động phụ luôn luôn nó sẽ thay đổi một cái gì đó trên máy chủ
PUT được sử dụng để đặt hoặc thay thế nội dung bằng chữ tại một URL cụ thể
Một sự khác biệt khác trong cả hai kiểu REST-Ful và không REST-Ful
POST là hoạt động không bình thường: Nó sẽ gây ra một số thay đổi nếu được thực hiện nhiều lần với cùng một yêu cầu.
PUT là hoạt động Idempotent: Nó sẽ không có tác dụng phụ nếu được thực hiện nhiều lần với cùng một yêu cầu.
Điều đáng nói POSTlà phải chịu một số cuộc tấn công giả mạo yêu cầu chéo trang web (CSRF) phổ biến trong khi PUTkhông.
CSRF dưới đây là không thểPUT khi nạn nhân đến thăm attackersite.com.
Ảnh hưởng của cuộc tấn công là nạn nhân vô tình xóa người dùng chỉ vì nó (nạn nhân) đã đăng nhập như admintrên target.site.com, trước khi truy cập attackersite.com:
Yêu cầu bình thường (cookie được gửi): ( PUTkhông phải là giá trị thuộc tính được hỗ trợ)
Mã trên 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>
Yêu cầu XHR (cookie được gửi): ( PUTsẽ kích hoạt yêu cầu preflight, phản hồi của họ sẽ ngăn trình duyệt yêu cầu deleteUsertrang)
var xhr = new XMLHttpRequest();
xhr.open("POST", "http://target.site.com/deleteUser");
xhr.withCredentials=true;
xhr.send(["userId=5"]);
Nói một cách đơn giản, bạn có thể nói:
1.HTTP Get: Nó được sử dụng để nhận một hoặc nhiều mục
2.HTTP Post: Nó được sử dụng để tạo một mục
3.HTTP Put: Nó được sử dụng để cập nhật một mục
4.HTTP Patch: Nó được sử dụng để cập nhật một phần vật phẩm
5.HTTP Xóa: Nó được sử dụng để xóa một mục
Trên thực tế không có sự khác biệt nào ngoài tiêu đề của họ. Thực sự có một sự khác biệt cơ bản giữa GET và những cái khác. Với phương thức "NHẬN" -Request, bạn gửi dữ liệu trong dòng địa chỉ url, được phân tách trước bằng dấu chấm hỏi và sau đó bằng dấu &.
Nhưng với phương thức "POST", bạn không thể truyền dữ liệu qua url, nhưng bạn phải truyền dữ liệu dưới dạng một đối tượng trong cái gọi là "cơ thể" của yêu cầu. Về phía máy chủ, sau đó bạn phải đọc phần nội dung nhận được để nhận dữ liệu đã gửi. Nhưng ở phía bên kia không có khả năng gửi nội dung trong cơ thể, khi bạn gửi "NHẬN" -Request.
Khiếu nại, rằng "NHẬN" chỉ để nhận dữ liệu và "POST" là để đăng dữ liệu, là hoàn toàn sai. Không ai có thể ngăn bạn tạo nội dung mới, xóa nội dung hiện có, chỉnh sửa nội dung hiện có hoặc làm bất cứ điều gì trong phần phụ trợ, dựa trên dữ liệu, được gửi bởi yêu cầu "NHẬN" hoặc theo yêu cầu "POST". Và không ai có thể ngăn bạn viết mã phụ trợ theo cách, với "POST" -Request, khách hàng yêu cầu một số dữ liệu.
Với một yêu cầu, cho dù bạn sử dụng phương thức nào, bạn gọi URL và gửi hoặc không gửi một số dữ liệu để chỉ định, thông tin nào bạn muốn chuyển đến máy chủ để giải quyết yêu cầu của bạn và sau đó khách hàng nhận được câu trả lời từ máy chủ. Dữ liệu có thể chứa bất cứ thứ gì bạn muốn gửi, phụ trợ được phép làm bất cứ điều gì nó muốn với dữ liệu và phản hồi có thể chứa bất kỳ thông tin nào bạn muốn đưa vào đó.
Chỉ có hai PHƯƠNG PHÁP CƠ BẢN này. NHẬN và ĐĂNG. Nhưng đó là cấu trúc của chúng, làm cho chúng khác biệt và không phải là những gì bạn viết mã trong phần phụ trợ. Trong phần phụ trợ, bạn có thể mã bất cứ điều gì bạn muốn, với dữ liệu nhận được. Nhưng với yêu cầu "POST", bạn phải gửi / truy xuất dữ liệu trong phần thân chứ không phải trong dòng địa chỉ url và với yêu cầu "NHẬN", bạn phải gửi / truy xuất dữ liệu trong dòng địa chỉ url chứ không phải trong cơ thể. Đó là tất cả.
Tất cả các phương thức khác, như "PUT", "XÓA", v.v., chúng có cùng cấu trúc với "POST".
Phương thức POST chủ yếu được sử dụng, nếu bạn muốn ẩn nội dung phần nào, bởi vì bất cứ điều gì bạn viết trong url-addressline, điều này sẽ được lưu trong bộ đệm và Phương thức GET giống như viết một địa chỉ url với dữ liệu. Vì vậy, nếu bạn muốn gửi dữ liệu nhạy cảm, không nhất thiết phải là tên người dùng và mật khẩu, nhưng ví dụ: một số id hoặc băm, mà bạn không muốn được hiển thị trong dòng địa chỉ url, thì bạn nên sử dụng phương thức POST .
Ngoài ra, độ dài của URL-Địa chỉ được giới hạn ở 1024 ký hiệu, trong khi "POST" -Method không bị hạn chế. Vì vậy, nếu bạn có lượng dữ liệu lớn hơn, bạn có thể không thể gửi nó với Yêu cầu NHẬN, nhưng bạn sẽ cần sử dụng Yêu cầu POST. Vì vậy, đây cũng là một điểm cộng khác cho yêu cầu POST.
Nhưng xử lý yêu cầu GET dễ dàng hơn khi bạn không có văn bản phức tạp để gửi. Mặt khác, và đây là một điểm cộng khác cho phương thức POST, đó là, với phương thức GET, bạn cần mã hóa url văn bản, để có thể gửi một số ký hiệu trong văn bản hoặc thậm chí là khoảng trắng. Nhưng với phương thức POST, bạn không bị hạn chế và nội dung của bạn không cần phải thay đổi hoặc thao túng theo bất kỳ cách nào.
Cả PUT và POST đều là Phương thức nghỉ.
PUT - Nếu chúng tôi thực hiện cùng một yêu cầu hai lần bằng PUT sử dụng cùng một tham số cả hai lần, yêu cầu thứ hai sẽ không có hiệu lực. Đây là lý do tại sao PUT thường được sử dụng cho kịch bản Cập nhật, gọi Cập nhật nhiều lần với cùng một tham số sẽ không làm gì hơn so với cuộc gọi ban đầu do đó PUT là tạm thời.
POST không phải là idempotent, ví dụ Tạo sẽ tạo hai mục riêng biệt vào mục tiêu do đó nó không phải là idempotent vì vậy CREATE được sử dụng rộng rãi trong POST.
Thực hiện cùng một cuộc gọi bằng cách sử dụng POST với cùng một tham số mỗi lần sẽ gây ra hai điều khác nhau xảy ra, do đó POST thường được sử dụng cho kịch bản Tạo