Tôi đang phát triển dịch vụ WCF REST và Theo lý thuyết tôi biết khi nào chọn tham gia cho mục đích gì.Sự khác biệt giữa các phương thức HTTP GET, POST, PUT và DELETE
GET để có được những tài nguyênPUT để cập nhậtPOST để ChènDELETE xóaNhưng nhược điểm là gì nếu chúng ta không làm theo quy tắc trên đây, giả sử để chèn một bản ghi tôi sử dụng phương pháp GET?
Nhưng bất lợi nếu chúng ta không tuân theo quy tắc trên, giả sử chèn bản ghi tôi đã sử dụng phương thức GET.
Công cụ tìm kiếm truy cập trang của bạn bằng yêu cầu GET, vì vậy nếu bạn làm như vậy, trình thu thập thông tin của Google có thể chèn các bản ghi mà bạn không muốn.
Thông thường, mọi người sẽ sử dụng POST cho bất kỳ loại yêu cầu ajax nào, với hành động thực tế trong nội dung của yêu cầu. Không có gì là sai với điều này, nhưng tính năng này là có cho bạn để sử dụng, vì vậy bạn cũng có thể sử dụng nó.
Vì phương thức HTTP GET được chỉ định là idempotent, một yêu cầu GET, theo đặc tả, có thể được gửi lại với giả định rằng nó sẽ không thay đổi bất cứ thứ gì trên máy chủ. Đây không phải là trường hợp cho một POST HTTP mà theo đặc điểm kỹ thuật có thể thay đổi trạng thái của ứng dụng đang chạy trên máy chủ.
Vì vậy, theo đặc điểm kỹ thuật, người ta có thể thực hiện một HTTP GET với một trang N số lần mà không đáng lo ngại về việc thay đổi trạng thái của nó.
Không tôn trọng đặc điểm kỹ thuật có thể có các kết quả không mong muốn khác nhau. Ví dụ: Trình thu thập thông tin web thực hiện theo yêu cầu GET để lập chỉ mục một trang web, chứ không phải POST. Nếu bạn đã cho phép yêu cầu HTTP GET thực hiện các thay đổi đối với cơ sở dữ liệu, bạn có thể dễ dàng hiểu được ý nghĩa không mong muốn mà nó có thể có.
Tôn trọng đặc điểm giống như tôn trọng thỏa thuận giữa dịch vụ hoặc trang web của bạn và một loạt người tiêu dùng khác nhau có thể là trình duyệt của người dùng bình thường nhưng cũng có các dịch vụ khác như trình thu thập dữ liệu web.
Bạn có thể tạo trang web sử dụng GET để chèn bản ghi nhưng bạn cũng nên mong đợi rằng mọi thứ được xây dựng xung quanh để tiêu thụ trang web của bạn hoạt động với giả định rằng bạn đang tôn trọng thỏa thuận.
Ví dụ cuối cùng, trình duyệt web cảnh báo người dùng khi họ cố gắng làm mới trang đã đạt được bằng yêu cầu HTTP POST cảnh báo rằng một số dữ liệu có thể được gửi lại. Bạn không nhận được lớp bảo vệ được tích hợp sẵn trong trình duyệt đó nếu trang được truy cập bằng yêu cầu HTTP GET.
Bạn có thể đọc thêm ở đây: http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
tôi phải đối mặt với một tình huống tôi nên đã sử dụng PUT thay vì GET. Tôi đã có một cuộc gọi chèn quyền truy cập vào một bên thứ ba (đây là google). Tôi quay một yêu cầu Ajax GET để cập nhật quyền gọi tới Servlet của tôi và từ cuộc gọi của họ đến dịch vụ bên ngoài. Dịch vụ bên ngoài mất khá nhiều thời gian để hoàn thành yêu cầu. Trong thời gian đó, tôi đã nhìn thấy sự trùng lặp của cùng một cuộc gọi cho phép trong nhật ký máy chủ của tôi. Đó là trình duyệt tiếp tục gọi máy chủ nói rằng bạn đã hoàn thành?vì nó là một GET và trình duyệt có thể gọi máy chủ nhiều lần nhất có thể. Trình duyệt theo tiêu chuẩn và mã của tôi thì không. Tôi đã gặp vấn đề không theo tiêu chuẩn.
Có lý do nào bạn muốn thực hiện việc này không? –
Tôi không biết tại sao chúng ta nên làm theo quy tắc trên, nếu chúng ta không làm theo thì bất lợi là gì? – Fooker
Công ước. Dự đoán. Tại sao bạn nên lái xe ở phía bên trái của đường (bên phải, ở Mỹ)? –