Phản hồi HTTP 412 - bạn có thể đưa nội dung vào không?

Question

Tôi đang xây dựng một kho lưu trữ dữ liệu RESTful và tận dụng GET và PUT có điều kiện. Trong PUT có điều kiện, máy khách có thể bao gồm Etag từ GET trước đó trên tài nguyên và nếu biểu diễn hiện tại không khớp với máy chủ sẽ trả lại mã trạng thái HTTP là 412 (Điều kiện tiên quyết không thành công). Lưu ý đây là một giao thức/máy chủ dựa trên Atom.

Câu hỏi của tôi là, khi tôi trả lại trạng thái 412, tôi có thể bao gồm đại diện mới của tài nguyên hoặc người dùng phải phát hành GET mới không? Đặc tả HTTP dường như không có hoặc không và không có đặc tả Atom (mặc dù ví dụ của chúng cho thấy một thực thể trống trên phản hồi). Nó có vẻ khá lãng phí không trả lại đại diện mới và làm cho khách hàng đặc biệt GET nó. Suy nghĩ?

Answer 1

Mặc dù GET có điều kiện và PUT được tóm tắt là 'yêu cầu có điều kiện', chúng rất khác nhau về mặt khái niệm. GET có điều kiện là một tối ưu hóa hiệu suất và các PUT có điều kiện là một cơ chế điều khiển đồng thời. Thật khó để thảo luận chúng lại với nhau.

Câu hỏi của bạn về GET có điều kiện: Nếu bạn gửi GET và bao gồm tiêu đề If-None-Match, máy chủ sẽ gửi 200 Ok nếu tài nguyên đã thay đổi và 304 Không được sửa đổi nếu không (nếu điều kiện không thành công) . 412 chỉ được sử dụng với các PUT có điều kiện.

CẬP NHẬT: Có vẻ như tôi đã đọc sai câu hỏi một chút. Về điểm của bạn liên quan đến 'làm mới' của bản sao cục bộ khi PUT có điều kiện thất bại: Có thể là bộ nhớ cache đã có phiên bản mới nhất và làm mới-GET của bạn sẽ được phục vụ từ một số bộ nhớ cache. Việc máy chủ trả về thực thể hiện tại với 412 thực sự có thể cho bạn hiệu năng kém hơn.

Answer 2

Không, về mặt kỹ thuật, bạn không nên. Mã lỗi thường chỉ định rằng đã xảy ra sự cố. Mặc dù không có gì ngăn bạn trả lại nội dung (và trên thực tế, một số lỗi như 404 trả lại một trang đẹp nói rằng Bạn không tìm thấy những gì bạn đang tìm), điểm phản hồi không trả lại nội dung khác, nhưng để trả lại một cái gì đó cho bạn biết những gì đã sai. Về mặt kỹ thuật, bạn cũng không nên trả lại dữ liệu đó vì bạn đã vượt qua If-None-Match: etag (Tôi giả định đó là những gì bạn đã vượt qua?)

Lưu ý khác, bạn có thực sự cần phải tối ưu hóa thêm một cuộc gọi http không?

Càng suy nghĩ về điều này, tôi càng tin rằng đó là một ý tưởng tồi - Bạn sẽ trả lại nội dung về bất kỳ lỗi nào khác? Ngữ nghĩa PUT là PUT. GET ngữ nghĩa nên được sử dụng cho GET.

Answer 3

Nếu số yêu cầu bổ sung phát sinh do yêu cầu thêm sau xung đột cập nhật, đủ quan trọng để bạn có mối quan tâm về hiệu suất, thì tôi khuyên bạn có thể gặp vấn đề với mức độ chi tiết của tài nguyên của bạn.

Bạn có thực sự mong đợi hàng triệu lần mỗi ngày nhiều người dùng sẽ chỉnh sửa cùng một tài nguyên cùng một lúc không? Có thể bạn cần lưu trữ các thay đổi delta cho tài nguyên thay vì cập nhật tài nguyên trực tiếp. Nếu thực sự có nhiều tranh cãi cho các tài nguyên này thì không phải người dùng sẽ liên tục làm việc với dữ liệu lỗi thời.

Nếu vấn đề của bạn là tài nguyên của bạn chứa ngày sửa đổi cuối cùng và người dùng được sửa đổi lần cuối và bạn phải thực hiện GET sau mỗi PUT thì tôi sẽ thuyết phục hơn về sự cần thiết phải xoay quy tắc.

Tuy nhiên, tôi nghĩ rằng hiệu suất đạt được của yêu cầu bổ sung đáng giá cho sự rõ ràng đối với nhà phát triển ứng dụng khách.