Tôi đã đọc rất nhiều thứ về điều này nhưng không thể đưa ra kết luận về chủ đề này.
Nhưng tôi chưa bao giờ sử dụng phương thức PUT hoặc DELETE HTTP Request. Xu hướng của tôi là sử dụng GET khi chỉ số của hệ thống (ứng dụng hoặc trang web của tôi) có thể không bị ảnh hưởng (như danh sách sản phẩm) và sử dụng POST khi nó bị ảnh hưởng (đặt hàng). Nó không đủ hay tôi đang thiếu thứ gì đó?
Câu trả lời:
DELETE là để xóa tài nguyên yêu cầu:
Phương thức DELETE yêu cầu máy chủ gốc xóa tài nguyên được xác định bởi URI Yêu cầu. Phương pháp này CÓ THỂ bị ghi đè bởi sự can thiệp của con người (hoặc các phương tiện khác) trên máy chủ gốc. Máy khách không thể được đảm bảo rằng hoạt động đã được thực hiện, ngay cả khi mã trạng thái được trả về từ máy chủ gốc cho biết rằng hành động đã được hoàn tất thành công…
PUT là để đưa hoặc cập nhật một tài nguyên trên máy chủ:
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. Nếu Request-URI đề cập đến một tài nguyên đã tồn tại, thực thể kèm theo NÊN được coi là phiên bản sửa đổi của tài nguyên nằm trên máy chủ gốc. Nếu URI yêu cầu không trỏ đến tài nguyên hiện có và URI đó có khả năng được tác nhân người dùng yêu cầu xác định là tài nguyên mới, thì máy chủ gốc có thể tạo tài nguyên bằng URI đó…
Để có thông số kỹ thuật đầy đủ, hãy truy cập:
Vì các trình duyệt hiện tại rất tiếc không hỗ trợ bất kỳ động từ nào khác ngoài POST và GET trong các biểu mẫu HTML , bạn thường không thể sử dụng HTTP ở mức độ đầy đủ với chúng (mặc dù bạn vẫn có thể chiếm quyền gửi của chúng thông qua JavaScript). Việc không hỗ trợ các phương pháp này trong các biểu mẫu HTML dẫn đến các URI chứa động từ, chẳng hạn như
POST http://example.com/order/1/delete
hoặc thậm chí tệ hơn
POST http://example.com/deleteOrder/id/1
hiểu ngữ nghĩa CRUD hiệu quả qua HTTP. Nhưng động từ không bao giờ có nghĩa là một phần của URI. Thay vào đó HTTP đã cung cấp cơ chế và ngữ nghĩa để CRUD một Tài nguyên (ví dụ: một đơn đặt hàng) thông qua các phương thức HTTP. HTTP là một giao thức chứ không chỉ là một số dịch vụ đường hầm dữ liệu.
Vì vậy, để xóa một Tài nguyên trên máy chủ web, bạn sẽ gọi
DELETE http://example.com/order/1
và để cập nhật nó, bạn sẽ gọi
PUT http://example.com/order/1
và cung cấp Biểu diễn tài nguyên được cập nhật trong phần thân PUT để máy chủ web áp dụng sau đó.
Vì vậy, nếu bạn đang xây dựng một số loại ứng dụng khách cho API REST , bạn có thể sẽ khiến nó gửi các yêu cầu PUT và DELETE. Đây có thể là một ứng dụng khách được xây dựng bên trong trình duyệt, ví dụ: gửi yêu cầu qua JavaScript hoặc nó có thể là một số công cụ chạy trên máy chủ, v.v.
Để biết thêm một số chi tiết, hãy truy cập:
Sử dụng động từ Yêu cầu HTTP như GET, POST, DELETE, PUT, v.v. cho phép bạn xây dựng các ứng dụng web RESTful. Đọc về nó tại đây: http://en.wikipedia.org/wiki/Representational_state_transfer
Cách dễ nhất để thấy được lợi ích từ việc này là xem ví dụ này. Mỗi khung công tác MVC đều có một Router/Dispatcherbản đồ URL đến các bộ điều khiển hành động. Vì vậy, URL như thế này: /blog/article/1sẽ gọi blogController::articleAction($id);
Bây giờ Bộ định tuyến này chỉ biết về URL hoặc/blog/article/1/
Nhưng nếu Bộ định tuyến đó biết toàn bộ đối tượng Yêu cầu HTTP thay vì chỉ URL, anh ta có thể có quyền truy cập động từ Yêu cầu HTTP (GET, POST, PUT, DELETE ...) và nhiều thứ hữu ích khác về HTTP Request hiện tại.
Điều đó sẽ cho phép bạn định cấu hình ứng dụng để nó có thể chấp nhận cùng một URL và ánh xạ nó tới các actionControllers khác nhau tùy thuộc vào động từ HTTP Request.
Ví dụ:
nếu bạn muốn truy xuất lại bài viết 1, bạn có thể làm như sau:
GET /blog/article/1 HTTP/1.1
nhưng nếu bạn muốn xóa bài viết 1, bạn sẽ làm điều này:
DELETE /blog/article/1 HTTP/1.1
Lưu ý rằng cả hai Yêu cầu HTTP đều có cùng một URI, / blog / article / 1, điểm khác biệt duy nhất là động từ Yêu cầu HTTP. Và dựa trên động từ đó, bộ định tuyến của bạn có thể gọi actionController khác nhau. Điều này cho phép bạn tạo các URL gọn gàng.
Đọc hai bài báo này, chúng có thể giúp bạn:
Symfony 2 - Nguyên tắc cơ bản về HTTP
Các bài viết này là về khung công tác Symfony 2, nhưng chúng có thể giúp bạn tìm ra cách thức hoạt động của Yêu cầu và phản hồi HTTP.
Hi vọng điêu nay co ich!
Createvà 1 cho Delete. Nếu bạn làm điều này, tìm kiếm tiếp theo của bạn sẽ là " Làm thế nào để có nhiều hành động Đăng trong một bộ điều khiển duy nhất ": P. Không phải điều này là tồi tệ, nhưng bạn mất khả năng có một tài nguyên duy nhất được thực hiện thông qua hành động động từ thay vì phải cung cấp rõ ràng tên hành động trong URI.
Mặc dù tôi có nguy cơ không được phổ biến, tôi nói rằng chúng không còn hữu ích ngày nay .
Tôi nghĩ rằng chúng đã được dự định tốt và hữu ích trong quá khứ khi ví dụ như DELETE yêu cầu máy chủ xóa tài nguyên được tìm thấy tại URL được cung cấp và PUT (với người anh em của nó là PATCH) yêu cầu máy chủ cập nhật theo cách không cần thiết.
Mọi thứ phát triển và URL trở nên ảo (xem ví dụ: viết lại url ) làm cho tài nguyên mất đi ý nghĩa ban đầu của thư mục / thứ tự con / tệp thực và do đó, các động từ hành động CRUD được bao phủ bởi các phương thức giao thức HTTP (GET, POST, PUT / PATCH, DELETE) bị mất dấu .
Hãy lấy một ví dụ:
Ở phía bên trái không được viết phương thức HTTP, về cơ bản nó không quan trọng (POST và GET là đủ) và ở bên phải các phương thức HTTP thích hợp được sử dụng.
Bên phải trông thanh lịch, sạch sẽ và chuyên nghiệp. Hãy tưởng tượng bây giờ bạn phải duy trì một mã đang sử dụng API thanh lịch và bạn phải tìm kiếm nơi thực hiện lệnh xóa. Bạn sẽ tìm kiếm "api / entity" và trong số các kết quả, bạn sẽ phải xem cái nào đang thực hiện XÓA. Hoặc thậm chí tệ hơn, bạn có một lập trình viên cấp dưới do nhầm lẫn đã chuyển PUT bằng DELETE và vì URL là điều tồi tệ xảy ra.
Theo ý kiến của tôi, việc đặt động từ hành động trong URL có lợi thế hơn so với việc sử dụng phương thức HTTP thích hợp cho hành động đó ngay cả khi nó không quá thanh lịch. Nếu bạn muốn xem nơi thực hiện lệnh xóa, bạn chỉ cần tìm kiếm "api / entity / delete" và bạn sẽ tìm thấy nó ngay lập tức.
Việc xây dựng một API mà không có toàn bộ mảng phương thức HTTP giúp nó dễ dàng được sử dụng và duy trì sau đó
Phương pháp an toàn: Nhận tài nguyên / Không sửa đổi tài nguyên
Lý tưởng: Không thay đổi trạng thái tài nguyên nếu được yêu cầu nhiều lần
Phương pháp không an toàn: Tạo hoặc cập nhật tài nguyên / Sửa đổi trong tài nguyên
Không phải Idempotent: Thay đổi trạng thái tài nguyên nếu được yêu cầu nhiều lần
Theo yêu cầu của bạn:
1) Để sử dụng hoạt động an toàn và không cố định (Tài nguyên tìm nạp) --------- NHẬN PHƯƠNG PHÁP
2) Để sử dụng hoạt động không an toàn và không phải là định hướng (Chèn tài nguyên) --------- PHƯƠNG PHÁP ĐĂNG
3) Đối với hoạt động không an toàn và không an toàn (Tài nguyên cập nhật), hãy sử dụng --------- PHƯƠNG PHÁP PUT
3) Đối với hoạt động không an toàn và không an toàn (Xóa tài nguyên), sử dụng --------- PHƯƠNG PHÁP XÓA