Tại sao dữ liệu không được sửa đổi trên yêu cầu HTTP GET?

Question

Tôi biết rằng việc sử dụng các phương thức không GET (POST, PUT, DELETE) để sửa đổi dữ liệu máy chủ là The Right Way để thực hiện mọi việc. Tôi có thể tìm thấy nhiều tài nguyên tuyên bố rằng yêu cầu GET không nên thay đổi tài nguyên trên máy chủ. Tuy nhiên, nếu một khách hàng đã đến với tôi hôm nay và nói "Tôi không quan tâm những gì The Way Right để làm việc là, nó dễ dàng hơn cho chúng tôi để sử dụng API của bạn nếu chúng ta chỉ có thể sử dụng các URL cuộc gọi và nhận được một số XML trở lại - chúng tôi không muốn phải xây dựng các yêu cầu HTTP và POST/PUT XML, "những gì lý do có lợi cho doanh nghiệp tôi có thể đưa ra để thuyết phục họ bằng cách khác?

Có các tác động bộ nhớ đệm không? Vân đê bảo mật? Tôi là loại tìm kiếm nhiều hơn là chỉ "nó không có ý nghĩa ngữ nghĩa" hoặc "nó làm cho mọi thứ mơ hồ."

Edit:

Cảm ơn câu trả lời cho đến nay liên quan đến tìm nạp trước. Tôi không quan tâm đến việc tìm nạp trước vì phần lớn là xung quanh việc sử dụng API mạng nội bộ và không thể truy cập vào các trang HTML có liên kết có thể được trình duyệt tìm nạp trước.

Answer 1

• Tìm nạp trước: Rất nhiều trình duyệt web sẽ sử dụng tính năng tìm nạp trước. Điều đó có nghĩa là nó sẽ tải một trang trước khi bạn nhấp vào liên kết. Dự đoán rằng bạn sẽ nhấp vào liên kết đó sau.
• Bots: Có một số bot quét và lập chỉ mục internet để biết thông tin. Họ sẽ chỉ phát hành yêu cầu GET. Bạn không muốn xóa nội dung nào đó từ yêu cầu GET vì lý do này.
• Lưu vào bộ nhớ cache: NHẬN các yêu cầu HTTP không được thay đổi trạng thái và chúng phải là idempotent. Idempotent có nghĩa là phát hành một yêu cầu một lần, hoặc phát hành nó nhiều lần cho cùng một kết quả. I E. Không có tác dụng phụ. Vì lý do này, các yêu cầu GET HTTP được gắn chặt với bộ nhớ đệm.
• Chuẩn HTTP cho biết: Tiêu chuẩn HTTP cho biết mỗi phương thức HTTP là gì. Một số chương trình được xây dựng để sử dụng tiêu chuẩn HTTP, và chúng giả định rằng bạn sẽ sử dụng nó theo cách bạn định làm. Vì vậy, bạn sẽ có hành vi không xác định từ một loạt các chương trình ngẫu nhiên nếu bạn không làm theo.

Answer 2

Làm cách nào Google tìm liên kết đến trang đó với tất cả các tham số GET trong URL và xem lại mọi lúc này? Điều đó có thể dẫn đến thảm họa.

Có một số funny article về điều này trên WTF hàng ngày.

Answer 3

Bảo mật một. Điều gì sẽ xảy ra nếu trình thu thập dữ liệu web đi qua liên kết xóa hoặc người dùng bị lừa nhấp vào liên kết? Người dùng nên biết họ đang làm gì trước khi họ thực sự làm điều đó.

Answer 4

Quyền truy cập có thể bị buộc đối với người dùng và dẫn đến yêu cầu Cross-site Forgery (CSRF). Ví dụ: nếu bạn có chức năng đăng xuất tại http://example.com/logout.php, thay đổi trạng thái máy chủ của người dùng, một người nguy hiểm có thể đặt thẻ hình ảnh trên bất kỳ trang web nào sử dụng URL ở trên làm nguồn của nó: http://example.com/logout.php. Tải mã này sẽ khiến người dùng đăng xuất. Không phải là một vấn đề lớn trong ví dụ được đưa ra, nhưng nếu đó là một lệnh để chuyển tiền ra khỏi một tài khoản, nó sẽ là một vấn đề lớn.

Answer 5

Lý do chính đáng để làm điều đó đúng cách ...

Chúng là tiêu chuẩn ngành, được ghi chép tài liệu và dễ bảo mật. Trong khi bạn hỗ trợ hoàn toàn cuộc sống dễ dàng nhất có thể cho khách hàng bạn không muốn thực hiện điều gì đó dễ dàng hơn trong ngắn hạn, tùy theo thứ gì đó không dễ dàng đối với họ nhưng mang lại lợi ích lâu dài.

Một trong những yêu thích của tôi trích dẫn

Nhanh chóng và bẩn ... lâu sau khi nhanh đã khởi hành phần còn lại bẩn.

Đối với bạn này là một "Một khâu trong thời gian tiết kiệm chín";)

Answer 6

An ninh: CSRF rất dễ dàng hơn nhiều trong các yêu cầu GET.

Sử dụng POST sẽ không bảo vệ bạn anyway nhưng GET có thể dẫn đến khai thác dễ dàng hơn và khai thác hàng loạt bằng cách sử dụng diễn đàn và địa điểm chấp nhận thẻ hình ảnh.

Tùy thuộc vào những gì bạn làm ở phía máy chủ bằng GET có thể giúp kẻ tấn công khởi chạy DoS (Từ chối dịch vụ). Một kẻ tấn công có thể spam hàng ngàn trang web với yêu cầu GET đắt tiền của bạn trong một thẻ hình ảnh và mỗi khách truy cập duy nhất của các trang web đó sẽ thực hiện yêu cầu GET đắt tiền này đối với máy chủ web của bạn. Mà sẽ gây ra rất nhiều chu kỳ CPU cho bạn.

Tôi biết rằng một số trang vẫn nặng và điều này luôn là rủi ro, nhưng rủi ro lớn hơn nếu bạn thêm 10 bản ghi lớn vào mỗi yêu cầu GET đơn lẻ.

Answer 7

Tôi là loại tìm kiếm nhiều hơn là chỉ "nó không có ý nghĩa ngữ nghĩa" hoặc "nó làm cho mọi thứ mơ hồ."

...

Tôi không quan tâm những gì đúng cách để làm những việc được, nó dễ dàng hơn cho chúng ta

Nói với họ để nghĩ về API tồi tệ nhất mà họ đã từng sử dụng. Họ có thể không tưởng tượng được điều đó gây ra bởi một hack nhanh chóng đã được mở rộng không?

Sẽ dễ dàng hơn (và rẻ hơn) trong 2 tháng nếu bạn bắt đầu bằng thứ gì đó có ý nghĩa ngữ nghĩa. Chúng tôi gọi nó là "Con đường đúng đắn" bởi vì nó làm mọi thứ dễ dàng hơn, không phải vì chúng tôi muốn tra tấn bạn.