Theo "hệ tư tưởng REST", những gì cần có trong cơ thể phản hồi cho các yêu cầu PUT / POST / DELETE?
Còn mã trả lại thì sao? Là HTTP_OKđủ?
Lý do cho các công ước như vậy, nếu có là gì?
Tôi đã tìm thấy một bài viết hay mô tả sự khác biệt của POST / PUT: POST so với PUT Nhưng nó vẫn không trả lời câu hỏi của tôi.
Câu trả lời:
Tha thứ cho flippancy, nhưng nếu bạn đang thực hiện REST qua HTTP thì RFC7231 mô tả chính xác hành vi nào được mong đợi từ GET, PUT, POST và DELETE.
Cập nhật (ngày 3 tháng 7 năm 14): Thông số
HTTP cố ý không xác định nội dung được trả về từ POST hoặc DELETE. Thông số kỹ thuật chỉ xác định những gì cần được xác định. Phần còn lại là tùy thuộc vào người thực hiện để lựa chọn.
Nhìn chung, các quy ước là những người nghĩ như bạn đang phân phối các trang web.
Đối với PUT, tôi sẽ trả lại cùng một chế độ xem mà bạn nhận được nếu bạn thực hiện GET ngay sau đó; điều đó sẽ dẫn đến 200 (tất nhiên, giả sử kết xuất thành công tất nhiên). Đối với POST, tôi sẽ chuyển hướng đến tài nguyên đã tạo (giả sử bạn đang thực hiện thao tác tạo; nếu không, chỉ cần trả về kết quả); mã để tạo thành công là năm 201, đây thực sự là mã HTTP duy nhất cho chuyển hướng không nằm trong phạm vi 300.
Tôi chưa bao giờ hài lòng về những gì XÓA sẽ trả lại (mã của tôi hiện đang tạo HTTP 204 và phần thân trống trong trường hợp này).
PUTtrở lại yêu cầu các trang tiếp theo có vẻ như một thói quen xấu, vì làm mới trên trang kết quả sẽ gây ra các yêu cầu để thực hiện một lần nữa. Thay vào đó, với tôi, thật hợp lý khi thực hiện chuyển hướng, giả sử bạn đang xử lý các yêu cầu đồng bộ.
PUTyêu cầu khác khiến dữ liệu được hoàn nguyên. Ví dụ: nếu hai người đang tham khảo cùng một trang, một người thực hiện cập nhật, thì người kia thực hiện cập nhật, nếu người đầu tiên làm mới để xem kết quả, nó sẽ thực sự khiến mọi thứ được hoàn nguyên trước khi người thứ hai thực hiện những thay đổi của họ.
Tạo một tài nguyên thường được ánh xạ tới POST và điều đó sẽ trả về vị trí của tài nguyên mới; ví dụ: trong Rails giàn giáo, CREATE sẽ chuyển hướng đến SHOW cho tài nguyên mới được tạo. Cách tiếp cận tương tự có thể có ý nghĩa đối với việc cập nhật (PUT), nhưng đó không phải là một quy ước; một bản cập nhật chỉ cần chỉ ra thành công. Một xóa có lẽ chỉ cần chỉ ra thành công là tốt; nếu bạn muốn chuyển hướng, trả về DANH SÁCH tài nguyên có lẽ có ý nghĩa nhất.
Thành công có thể được chỉ định bởi HTTP_OK, vâng.
Quy tắc khó và nhanh duy nhất trong những gì tôi đã nói ở trên là TẠO nên trả về vị trí của tài nguyên mới. Điều đó có vẻ như không có trí tuệ đối với tôi; nó có ý nghĩa hoàn hảo rằng khách hàng sẽ cần có thể truy cập vào mục mới.
Bởi RFC7231 không thành vấn đề và có thể trống
Cách chúng tôi thực hiện giải pháp dựa trên tiêu chuẩn json api trong dự án:
post / put: xuất các thuộc tính đối tượng như trong get (bộ lọc trường / quan hệ áp dụng như nhau)
xóa: dữ liệu chỉ chứa null (vì nó đại diện cho đối tượng bị thiếu)
trạng thái xóa tiêu chuẩn: 200
Tôi thích ứng dụng trả lời Alfonso Tienda từ mã trạng thái HTTP để cập nhật và xóa?
Dưới đây là một số lời khuyên:
XÓA BỎ
200 (nếu bạn muốn gửi một số dữ liệu bổ sung trong Phản hồi) hoặc 204 (được khuyến nghị).
Thao tác 202 đã bị xóa chưa được cam kết.
Nếu không có gì để xóa, hãy sử dụng 204 hoặc 404 (Thao tác XÓA là không cần thiết, xóa một mục đã bị xóa là hoạt động thành công , vì vậy bạn có thể trả về 204 , nhưng sự thật là idempotent không nhất thiết phải có cùng một phản hồi)
Các lỗi khác:
- 400 Yêu cầu Không hợp lệ (Cú pháp sai hoặc truy vấn xấu là lạ nhưng có thể).
- 401 Lỗi xác thực trái phép
- 403 Cấm : Lỗi ủy quyền hoặc ID ứng dụng không hợp lệ.
- 405 Không được phép . Chắc chắn rồi.
- 409 Xung đột tài nguyên có thể có thể có trong các hệ thống phức tạp.
- Và 501 , 502 trong trường hợp có lỗi.
ĐẶT
Nếu bạn đang cập nhật một yếu tố của bộ sưu tập
- 200/204 với các lý do tương tự như XÓA ở trên.
- 202 nếu hoạt động chưa được cam kết.
Phần tử được tham chiếu không tồn tại:
PUT có thể là 201 (nếu bạn đã tạo phần tử vì đó là hành vi của bạn)
404 Nếu bạn không muốn tạo các phần tử qua PUT.
400 Yêu cầu Không hợp lệ (Cú pháp không đúng hoặc một truy vấn xấu phổ biến hơn trong trường hợp XÓA).
401 trái phép
403 Bị cấm : Lỗi xác thực hoặc ID ứng dụng không hợp lệ.
405 Không được phép . Chắc chắn rồi.
409 Xung đột tài nguyên có thể có thể xảy ra trong các hệ thống phức tạp, như trong XÓA.
422 Thực thể không thể xử lý Nó giúp phân biệt giữa "Yêu cầu xấu" (ví dụ: XML / JSON không đúng định dạng) và các giá trị trường không hợp lệ
Và 501 , 502 trong trường hợp có lỗi.