Mã trạng thái HTTP để cập nhật và xóa?

Tôi nên đặt mã trạng thái nào cho UPDATE( PUT) và DELETE(ví dụ: sản phẩm được cập nhật thành công)?

Đối với yêu cầu PUT : HTTP 200 hoặc HTTP 204 nên ngụ ý "tài nguyên được cập nhật thành công".

Đối với yêu cầu XÓA : HTTP 200 hoặc HTTP 204 nên ngụ ý "tài nguyên đã được xóa thành công". HTTP 202 cũng có thể được trả về, điều đó có nghĩa là lệnh được máy chủ chấp nhận và "tài nguyên được đánh dấu để xóa".

ĐẶT

Nếu tài nguyên hiện có được sửa đổi, mã phản hồi 200 (OK) hoặc 204 (Không có nội dung)> NÊN được gửi để cho biết hoàn thành yêu cầu thành công.

XÓA BỎ

Phản hồi thành công NÊN 200 (OK) nếu phản hồi bao gồm một thực thể mô tả trạng thái, 202 (Được chấp nhận) nếu hành động chưa được ban hành hoặc 204 (Không có nội dung) nếu hành động đã được ban hành nhưng phản hồi không bao gồm một thực thể.

Nguồn: W3.org: Định nghĩa phương thức HTTP / 1.1

HTTP 200 OK: Phản hồi tiêu chuẩn cho các yêu cầu HTTP thành công. Đáp ứng thực tế sẽ phụ thuộc vào phương thức yêu cầu được sử dụng.

HTTP 204 Không có nội dung: Máy chủ đã xử lý yêu cầu thành công, nhưng không trả lại bất kỳ nội dung nào

Nguồn: Danh sách mã trạng thái HTTP: 2xx Thành công

Câu trả lời ngắn: cho cả PUT và DELETE, bạn nên gửi 200 (OK) hoặc 204 (Không có nội dung).

Câu trả lời dài: đây là một sơ đồ quyết định hoàn chỉnh (bấm vào để phóng to).

Nguồn: https://github.com/for-GET/http-decision-diagram

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 phản hồi giống nhau)

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.

RFC 2616 mô tả mã trạng thái sẽ sử dụng .

Và không, không phải lúc nào cũng là 200.

Ngoài 200 và 204, 205 (Đặt lại nội dung) có thể là một phản hồi hợp lệ.

Máy chủ đã hoàn thành yêu cầu và tác nhân người dùng NÊN đặt lại chế độ xem tài liệu khiến yêu cầu được gửi ... [ví dụ] xóa biểu mẫu trong đó đầu vào được đưa ra.

Vì câu hỏi đi sâu vào việc nếu XÓA "nên" trả về 200 so với 204 , đáng để xem xét rằng một số người khuyên nên trả lại một thực thể có liên kết để ưu tiên là 200 .

"Thay vì trả về 204 (Không có nội dung), API sẽ hữu ích và gợi ý những nơi cần đến. Trong ví dụ này tôi nghĩ một liên kết rõ ràng để cung cấp là" 'where.com/container/' (trừ 'resource') "- vùng chứa mà khách hàng vừa xóa một tài nguyên. Có lẽ khách hàng muốn xóa thêm tài nguyên, vì vậy đó sẽ là một liên kết hữu ích. "

http://blog.ploeh.dk/2013/04/30/rest-lesson-learned-avoid-204-responses/

Nếu khách hàng gặp phải phản hồi 204, họ có thể từ bỏ, đi đến điểm vào của API hoặc quay lại tài nguyên trước đó mà nó đã truy cập. Không có lựa chọn nào là đặc biệt tốt.

Cá nhân tôi sẽ không nói 204 là sai (tác giả cũng không nói "gây phiền nhiễu") vì bộ nhớ đệm tốt ở phía khách hàng có nhiều lợi ích. Tốt nhất là phải nhất quán một trong hai cách.

Đây là một số mã trạng thái, mà bạn nên biết cho loại kiến ​​thức của bạn.

Phản hồi thông tin 1XX

• 100 Tiếp tục
• 101 giao thức chuyển đổi
• 102 Chế biến
• 103 gợi ý sớm

2XX thành công

• 200 OK
• 201 tạo
• 202 được chấp nhận
• 203 Thông tin không có thẩm quyền
• 204 Không có nội dung
• 205 Đặt lại nội dung
• 206 Nội dung một phần
• 207 Đa trạng thái
• 208 Đã báo cáo
• 226 IM được sử dụng

Chuyển hướng 3XX

• 300 lựa chọn
• 301 di chuyển vĩnh viễn
• 302 Tìm thấy
• 303 Xem khác
• 304 không được sửa đổi
• 304 Sử dụng Proxy
• 306 Chuyển đổi proxy
• 307 Chuyển hướng tạm thời
• Chuyển hướng vĩnh viễn 308

Lỗi máy khách 4XX

• 400 yêu cầu xấu
• 401 trái phép
• 402 Thanh toán Required
• 403 Cấm
• 404 Không tìm thấy
• 405 Phương pháp không được phép
• 406 Không được chấp nhận
• 407 Yêu cầu xác thực Proxy
• 408 Thời gian chờ yêu cầu
• 409 Xung đột
• 410 qua
• 411 Yêu cầu chiều dài
• 412 Điều kiện không thành công
• 413 Tải trọng quá lớn
• 414 URI quá dài
• 415 Loại phương tiện không được hỗ trợ
• 420 Phạm vi không thỏa đáng
• 417 vọng Không
• 418 Tôi là một ấm trà
• 420 Phương pháp thất bại
• 421 Yêu cầu sai
• 422 Thực thể không thể xử lý
• 423 khóa
• 424 Phụ thuộc thất bại
• 426 Yêu cầu nâng cấp
• 428 kiện tiên quyết buộc
• 429 quá nhiều yêu cầu
• 431 Trường tiêu đề yêu cầu quá lớn
• 451 Không có sẵn cho các lý do pháp lý

Lỗi máy chủ 5XX

• Lỗi 500 máy chủ nội bộ
• 501 Không được thực hiện
• Cổng xấu 502
• 503 Dịch vụ không khả dụng
• Thời gian chờ 504 cổng
• Phiên bản 505 http không được hỗ trợ
• 506 Biến cũng thương lượng
• 507 Lưu trữ không đủ
• Đã phát hiện vòng lặp 508
• 510 không được mở rộng
• Yêu cầu xác thực mạng 511

Vào tháng 6 năm 2014 RFC7231 lỗi thời RFC2616. 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

Khi tài nguyên được sửa đổi, mã phản hồi phải là 200 ( Lúc OK OK) . Nếu trạng thái tài nguyên thay đổi theo cách thay đổi URI thành tài nguyên (ví dụ: tài khoản người dùng được đổi tên), mã phản hồi là 301 (Chuyển động vĩnh viễn) và tiêu đề Vị trí sẽ cung cấp URI mới.

Khi một đối tượng bị xóa, mã phản hồi sẽ là 200 (Hiện OK OK).

Theo liên kết dưới đây để biết thêm chi tiết - mã trạng thái cho phần còn lại