Tại sao chúng ta cần gì hơn HTTP GET, PUT, POST?

Question

Lợi ích thiết thực của việc sử dụng HTTP GET, PUT, DELETE, POST, HEAD là gì? Tại sao không tập trung vào lợi ích hành vi của họ (an toàn và idempotency), quên tên của họ, và sử dụng GET, PUT hoặc POST tùy thuộc vào hành vi chúng ta muốn?

Tại sao chúng ta không nên sử dụng GET, PUT và POST (và thả HEAD, DELETE)?

Answer 1

Cách tiếp cận [REST] [1] sử dụng POST, GET, PUT và DELETE để triển khai các quy tắc CRUD cho tài nguyên web. Đó là một cách đơn giản và ngăn nắp để hiển thị các đối tượng cho các yêu cầu trên web. Đó là các dịch vụ web không có chi phí.

Chỉ cần làm rõ sự khác biệt ngữ nghĩa. Mỗi hoạt động khá khác nhau. Vấn đề là có các phương thức HTTP đẹp có ý nghĩa rõ ràng, khác biệt.

POST tạo đối tượng mới. URI không có khóa; nó chấp nhận một thân thông báo định nghĩa đối tượng. Chèn SQL. [Chỉnh sửa Mặc dù không có lý do kỹ thuật nào cho POST không có khóa, nhưng các nhân viên REST đề xuất mạnh mẽ rằng để POST có ý nghĩa riêng biệt như CREATE, nó không có khóa.]

GET truy xuất các đối tượng hiện có. URI có thể có khóa, tùy thuộc vào việc bạn đang thực hiện GET đơn hoặc danh sách GET. SQL Chọn

PUT cập nhật một đối tượng hiện có. URI có khóa; Nó chấp nhận một nội dung thông báo cập nhật một đối tượng. Cập nhật SQL.

DELETE xóa đối tượng hiện có. URI có khóa. Xóa SQL.

Bạn có thể cập nhật bản ghi bằng POST thay vì PUT không? Không phải không giới thiệu một số sự mơ hồ. Động từ nên có những hiệu ứng rõ ràng. Hơn nữa, POST URI không có khóa, trong đó PUT phải có khóa.

Khi tôi POST, tôi mong đợi một TẠO TẠO 201. Nếu tôi không hiểu, có gì đó không ổn. Tương tự, khi tôi PUT, tôi mong đợi một 200 OK. Nếu tôi không hiểu, có gì đó không ổn.

Tôi cho rằng bạn có thể nhấn mạnh vào một số sự mơ hồ trong đó POST thực hiện POST hoặc PUT. URI phải khác; cũng thông điệp liên quan có thể khác nhau. Nói chung, các thành viên REST lấy cue của họ từ SQL, nơi INSERT và UPDATE là các động từ khác nhau.

Bạn có thể đặt trường hợp UPDATE sẽ chèn nếu bản ghi không tồn tại hoặc cập nhật nếu bản ghi không tồn tại. Tuy nhiên, nó đơn giản hơn nếu UPDATE có nghĩa là UPDATE và không cập nhật có nghĩa là có gì đó sai. Một trở lại bí mật để INSERT làm cho các hoạt động mơ hồ.

Nếu bạn không xây dựng giao diện RESTful, thì điển hình là chỉ sử dụng GET và POST để truy xuất và tạo/cập nhật. Thông thường, có sự khác biệt về URI hoặc sự khác biệt về nội dung thư để phân biệt giữa POST và PUT khi một người nhấp vào gửi trên biểu mẫu. Tuy nhiên, nó không phải là rất sạch vì mã của bạn phải xác định xem bạn có đang ở trong trường hợp POST = create case hoặc POST = update hay không.

Answer 2

Tại sao chúng tôi cần nhiều hơn POST? Nó cho phép dữ liệu lưu thông cả hai cách, vậy tại sao GET lại cần thiết? Câu trả lời về cơ bản giống như câu hỏi của bạn. Bằng cách tiêu chuẩn hóa các kỳ vọng cơ bản của các phương pháp khác nhau, các quy trình khác có thể biết rõ hơn về những việc cần làm.

Ví dụ, các proxy đệm tạm thời có thể có cơ hội thực hiện chính xác hơn.

Suy nghĩ về HEAD chẳng hạn. Nếu máy chủ proxy biết HEAD có nghĩa là gì thì nó có thể xử lý kết quả từ một yêu cầu GET trước đó để cung cấp câu trả lời đúng cho yêu cầu HEAD. Và nó có thể biết rằng POST, PUT và DELETE không nên được lưu trữ.

Answer 3

Không phải tất cả máy chủ đều không hỗ trợ PUT, DELETE.

Tôi hỏi câu hỏi này, trong một thế giới lý tưởng chúng tôi có tất cả các động từ nhưng ....:

RESTful web services and HTTP verbs

Answer 4

Để hạn chế nhập nhằng mà sẽ cho phép cho tốt hơn/dễ dàng tái sử dụng của REST đơn giản của chúng tôi apis.

Answer 5

Bạn chỉ có thể sử dụng GET và POST nhưng sau đó bạn sẽ mất đi một số độ chính xác và rõ ràng mà PUT và DELETE mang lại. POST là một hoạt động ký tự đại diện có thể có nghĩa là bất cứ điều gì. Hành vi của PUT và DELETE được xác định rất rõ. Nếu bạn nghĩ về một API quản lý tài nguyên thì GET, PUT và DELETE có thể bao gồm 80% -90% chức năng được yêu cầu. Nếu bạn tự giới hạn GET và POST thì 40% -60% api của bạn được truy cập bằng cách sử dụng POST được chỉ định kém.

Answer 6

Cuộc chiến máy chủ web từ những ngày trước đó có thể gây ra.

Trong HTTP 1.0 written in 1996, there were only GET, HEAD, and POST. Nhưng như bạn có thể thấy trong Appendix D, các nhà cung cấp bắt đầu thêm những thứ của riêng họ. Vì vậy, để giữ cho HTTP tương thích, họ buộc phải thực hiện HTTP 1.1 in 1999.

Tuy nhiên, HTTP/1.0 không đủ đi vào xem xét những ảnh hưởng của proxy phân cấp, bộ nhớ đệm, nhu cầu kết nối liên tục, hoặc máy ảo. Ngoài ra, sự gia tăng của các ứng dụng không hoàn toàn được gọi là "HTTP/1.0" đã yêu cầu thay đổi phiên bản giao thức để hai ứng dụng giao tiếp xác định khả năng thực sự của nhau.

Đặc tả này xác định giao thức được gọi là "HTTP/1.1". Giao thức này bao gồm các yêu cầu nghiêm ngặt hơn HTTP/1.0 theo thứ tự để đảm bảo thực hiện đáng tin cậy các tính năng của nó.

Answer 7

Ứng dụng web sử dụng GET và POST cho phép người dùng tạo, xem, sửa đổi và xóa dữ liệu của họ, nhưng làm như vậy ở một lớp phía trên lệnh HTTP được tạo ban đầu cho các mục đích này. Một trong những ý tưởng đằng sau REST là một trở về mục đích ban đầu của thiết kế Web, theo đó có các hoạt động HTTP cụ thể cho mỗi động từ CRUD.

Ngoài ra, lệnh HEAD có thể được sử dụng để cải thiện trải nghiệm người dùng cho các tệp tải xuống (có khả năng lớn). Bạn gọi HEAD để tìm hiểu xem phản hồi sẽ lớn như thế nào và sau đó gọi GET để thực sự truy xuất nội dung.

Answer 8

Xem link sau đây để có ví dụ minh họa. Nó cũng gợi ý một cách để sử dụng phương pháp http OPTIONS, mà vẫn chưa được thảo luận ở đây.

Answer 9

GET, PUT, DELETE và POST là lưu trữ từ thời đại khi sinh viên năm thứ hai nghĩ rằng một trang web có thể bị giảm xuống một vài nguyên tắc hoighty-toity.

Ngày nay, hầu hết các trang web là các đối tượng hỗn hợp, chứa một số hoặc tất cả các hoạt động nguyên thủy này.Ví dụ: một trang có thể có biểu mẫu để xem hoặc cập nhật thông tin khách hàng, có thể mở rộng một số bảng.

Tôi thường sử dụng $ _REQUEST [] bằng php, không thực sự quan tâm cách thông tin đến. Tôi sẽ chọn sử dụng các phương thức GET hoặc PUT dựa trên hiệu quả, chứ không phải các mô hình cơ bản (nhiều).

Answer 10

POST không đảm bảo là safety or idempotency. Đó là một lý do cho PUT và DELETE —báo PUT và DELETE không có giá trị (nghĩa là, 1 + N yêu cầu giống nhau có cùng kết quả như chỉ 1 yêu cầu).

PUT được sử dụng để đặt trạng thái tài nguyên tại URI đã cho. Khi bạn gửi yêu cầu POST tới tài nguyên tại một URI cụ thể, tài nguyênkhông được là thay thế theo nội dung. Tối đa, nó phải là được nối thêm vào. Đây là lý do POST không phải là idempotent — trong trường hợp POSTS phụ thêm, mọi yêu cầu sẽ thêm vào tài nguyên (ví dụ: mỗi lần đăng thư mới vào diễn đàn thảo luận).

DELETE được sử dụng để đảm bảo rằng tài nguyên tại URI đã cho bị xóa khỏi máy chủ. POST thường không được sử dụng để xóa trừ trường hợp gửi yêu cầu xóa. Một lần nữa, URI của tài nguyên bạn sẽ POST trong trường hợp đó không phải là URI cho tài nguyên mà bạn muốn xóa. Bất kỳ tài nguyên nào bạn gửi đến là tài nguyên chấp nhận dữ liệu đã đăng để tự thêm vào, thêm vào bộ sưu tập hoặc xử lý theo cách khác.

HEAD được sử dụng nếu tất cả những gì bạn quan tâm là tiêu đề của yêu cầu GET và bạn không muốn lãng phí băng thông trên nội dung thực tế. Điều này là tốt đẹp để có.

Answer 11

Không ai đăng loại câu trả lời mà tôi đang tìm kiếm vì vậy tôi sẽ cố gắng tóm tắt các điểm chính mình.

"Dịch vụ web RESTful" chương 8 "Overloading POST" đọc: "Nếu bạn muốn làm mà không có PUT và DELETE hoàn toàn, nó hoàn toàn RESTful để hiển thị các hoạt động an toàn trên tài nguyên thông qua GET và tất cả các hoạt động khác thông qua POST quá tải. Làm điều này vi phạm Kiến trúc hướng tài nguyên của tôi, nhưng nó tuân theo các quy tắc ít hạn chế hơn của REST. "

Tóm lại, thay thế PUT/DELETE có lợi cho POST làm cho API khó đọc hơn và các lệnh gọi PUT/DELETE không còn là số không độc lập.

Answer 12

Có các tiện ích mở rộng http như WebDAV yêu cầu bổ sung chức năng.

http://en.wikipedia.org/wiki/WebDAV

Answer 13

Trong một từ:

idempotency

Trong một vài lời hơn:

GET = an toàn + idempotent

PUT = idempotent

DELETE = idempotent

POST = không an toàn hoặc không đáng tin cậy

'Idempotent' chỉ có nghĩa là bạn có thể lặp đi lặp lại và nó sẽ luôn làm chính xác như vậy.

Bạn có thể phát hành lại yêu cầu PUT (cập nhật) hoặc DELETE bao nhiêu lần tùy ý và nó sẽ có tác dụng tương tự mỗi lần, tuy nhiên hiệu ứng mong muốn sẽ thay đổi tài nguyên để nó không được coi là 'an toàn'.

Yêu cầu POST sẽ tạo tài nguyên mới với mọi yêu cầu, nghĩa là hiệu ứng sẽ khác nhau mỗi lần. Do đó POST không được coi là an toàn hoặc không đáng kể.

Các phương thức như GET và HEAD chỉ là các hoạt động đọc và do đó được coi là 'an toàn' cũng như không có giá trị.

Đây thực sự là một khái niệm khá quan trọng vì nó cung cấp cách tiêu chuẩn/nhất quán để diễn giải giao dịch HTTP; điều này đặc biệt hữu ích trong bối cảnh bảo mật.

Answer 14

HEAD thực sự hữu ích để xác định đồng hồ của máy chủ đã cho được đặt thành (chính xác trong khoảng thời gian 1 giây hoặc thời gian khứ hồi mạng, tùy theo mức nào lớn hơn). Nó cũng tuyệt vời để nhận báo giá Futurama từ Slashdot:

~$ curl -I slashdot.org 
HTTP/1.1 200 OK 
Date: Wed, 29 Oct 2008 05:35:13 GMT 
Server: Apache/1.3.41 (Unix) mod_perl/1.31-rc4 
SLASH_LOG_DATA: shtml 
X-Powered-By: Slash 2.005001227 
X-Fry: That's a chick show. I prefer programs of the genre: World's Blankiest Blank. 
Cache-Control: private 
Pragma: private 
Connection: close 
Content-Type: text/html; charset=iso-8859-1

Đối cURL, -I là lựa chọn để thực hiện một yêu cầu HEAD. Để có được ngày và giờ hiện tại của một máy chủ nhất định, chỉ cần thực hiện

curl -I $server | grep ^Date