Mã phản hồi HTTP cho POST khi tài nguyên đã tồn tại

Tôi đang xây dựng một máy chủ cho phép khách hàng lưu trữ các đối tượng. Các đối tượng đó được xây dựng đầy đủ ở phía máy khách, hoàn thành với ID đối tượng là vĩnh viễn cho toàn bộ vòng đời của đối tượng.

Tôi đã xác định API để khách hàng có thể tạo hoặc sửa đổi các đối tượng bằng PUT:

PUT /objects/{id} HTTP/1.1
...

{json representation of the object}

{Id} là ID đối tượng, vì vậy nó là một phần của URI yêu cầu.

Bây giờ, tôi cũng đang xem xét cho phép khách hàng tạo đối tượng bằng POST:

POST /objects/ HTTP/1.1
...

{json representation of the object, including ID}

Vì POST có nghĩa là hoạt động "chắp thêm", tôi không chắc phải làm gì trong trường hợp đối tượng đã ở đó. Tôi nên coi yêu cầu là yêu cầu sửa đổi hay tôi nên trả lại một số mã lỗi (cái nào)?

Cảm giác của tôi là 409 Conflictthích hợp nhất, tuy nhiên, hiếm khi được nhìn thấy trong tự nhiên:

Yêu cầu không thể được hoàn thành do xung đột với trạng thái hiện tại của tài nguyên. Mã này chỉ được phép trong các tình huống mà người dùng dự kiến ​​có thể giải quyết xung đột và gửi lại yêu cầu. Cơ quan phản hồi NÊN bao gồm đủ thông tin để người dùng nhận ra nguồn gốc của xung đột. Lý tưởng nhất, thực thể phản hồi sẽ bao gồm đủ thông tin cho người dùng hoặc tác nhân người dùng để khắc phục sự cố; tuy nhiên, điều đó có thể là không thể và không bắt buộc.

Xung đột rất có thể xảy ra để đáp ứng yêu cầu PUT. Ví dụ: nếu phiên bản đang được sử dụng và thực thể là PUT bao gồm các thay đổi đối với tài nguyên xung đột với tài nguyên được tạo bởi yêu cầu trước đó (bên thứ ba), máy chủ có thể sử dụng phản hồi 409 để cho biết rằng nó không thể hoàn thành yêu cầu . Trong trường hợp này, thực thể phản hồi có thể sẽ chứa một danh sách các khác biệt giữa hai phiên bản theo định dạng được xác định bởi Kiểu nội dung phản hồi.

Theo RFC 7231 , 303 See Other CÓ THỂ được sử dụng Nếu kết quả xử lý POST sẽ tương đương với đại diện của tài nguyên hiện có .

Cá nhân tôi đi với phần mở rộng WebDAV 422 Unprocessable Entity.

Theo RFC 4918

Các 422 Unprocessable Entitymã trạng thái nghĩa là máy chủ hiểu được kiểu nội dung của đối tượng yêu cầu (do đó một 415 Unsupported Media Typemã trạng thái là không phù hợp), và cú pháp của tổ chức yêu cầu là chính xác (do đó một 400 Bad Requestmã trạng thái là không phù hợp) nhưng không thể xử lý các hướng dẫn kín.

Đó là tất cả về bối cảnh và cũng là người chịu trách nhiệm xử lý các bản sao trong các yêu cầu (máy chủ hoặc máy khách hoặc cả hai)

Nếu máy chủ chỉ trỏ trùng lặp , hãy xem 4xx:

• 400 Yêu cầu Không hợp lệ - khi máy chủ không xử lý yêu cầu vì đó là lỗi máy khách rõ ràng
• 409 Xung đột - nếu máy chủ sẽ không xử lý yêu cầu, nhưng lý do cho điều đó không phải là lỗi của khách hàng
• ...

Để xử lý ngầm các bản sao, hãy xem 2XX:

• 200 OK
• 201 tạo
• ...

nếu máy chủ dự kiến ​​sẽ trả lại một cái gì đó , hãy xem 3XX:

• Tìm thấy 302
• 303 Xem khác
• ...

khi máy chủ có thể trỏ tài nguyên hiện có, nó ngụ ý chuyển hướng.

Nếu những điều trên là không đủ, thì luôn luôn là một cách tốt để chuẩn bị một số thông báo lỗi trong phần thân của phản hồi.

Có thể muộn trò chơi nhưng tôi đã vấp phải vấn đề ngữ nghĩa này trong khi cố gắng tạo API REST.

Để mở rộng một chút về câu trả lời của Wrikken, tôi nghĩ bạn có thể sử dụng 409 Conflicthoặc 403 Forbiddentùy thuộc vào tình huống - tóm lại, sử dụng lỗi 403 khi người dùng hoàn toàn không thể làm gì để giải quyết xung đột và hoàn thành yêu cầu (ví dụ: họ không thể gửi DELETEyêu cầu xóa tài nguyên một cách rõ ràng) hoặc sử dụng 409 nếu có thể có thể thực hiện được.

10,4,4 403 Cấm

Máy chủ hiểu yêu cầu, nhưng từ chối thực hiện nó. Ủy quyền sẽ không giúp đỡ và yêu cầu KHÔNG NÊN lặp lại. Nếu phương thức yêu cầu không phải là CHÍNH và máy chủ muốn công khai lý do tại sao yêu cầu chưa được thực hiện, thì NÊN mô tả lý do từ chối trong thực thể. Nếu máy chủ không muốn cung cấp thông tin này cho khách hàng, mã trạng thái 404 (Không tìm thấy) có thể được sử dụng thay thế.

Ngày nay, có người nói "403" và vấn đề về quyền hoặc xác thực xuất hiện, nhưng thông số kỹ thuật nói rằng về cơ bản, máy chủ nói với khách hàng rằng họ sẽ không làm điều đó, đừng hỏi lại và đây là lý do khách hàng không nên hỏi lại 't.

Vì PUTso với POST... POSTnên được sử dụng để tạo một phiên bản mới của tài nguyên khi người dùng không có phương tiện hoặc không nên tạo định danh cho tài nguyên. PUTđược sử dụng khi danh tính của tài nguyên được biết đến.

9,6 PUT

...

Sự khác biệt cơ bản giữa các yêu cầu POST và PUT được phản ánh theo nghĩa khác nhau của URI yêu cầu. URI trong yêu cầu POST xác định tài nguyên sẽ xử lý thực thể kèm theo. Tài nguyên đó có thể là một quá trình chấp nhận dữ liệu, một cổng vào một số giao thức khác hoặc một thực thể riêng biệt chấp nhận các chú thích. Ngược lại, URI trong yêu cầu PUT xác định thực thể kèm theo yêu cầu - tác nhân người dùng biết URI được dự định là gì và máy chủ KHÔNG cố gắng áp dụng yêu cầu cho một số tài nguyên khác. Nếu máy chủ mong muốn rằng yêu cầu được áp dụng cho một URI khác,

nó PHẢI gửi phản hồi 301 (Đã di chuyển vĩnh viễn); tác nhân người dùng CÓ THỂ đưa ra quyết định của riêng mình về việc có chuyển hướng yêu cầu hay không.

"302 Found" nghe có vẻ hợp lý đối với tôi. Và RFC 2616 nói rằng nó CÓ THỂ được trả lời cho các yêu cầu khác ngoài GET và HEAD (và điều này chắc chắn bao gồm POST)

Nhưng nó vẫn giữ cho khách truy cập truy cập URL này để nhận tài nguyên "Tìm thấy" này, bởi RFC. Để làm cho nó đi trực tiếp đến URL "Đã tìm thấy" thực sự, bạn nên sử dụng "303 See Other", điều này có ý nghĩa, nhưng buộc một cuộc gọi khác phải NHẬN URL sau. Về mặt tốt, GET này là bộ nhớ cache.

Tôi nghĩ rằng tôi sẽ sử dụng "303 See Other" . Tôi không biết liệu tôi có thể phản hồi với "thứ" được tìm thấy trong cơ thể không, nhưng tôi muốn làm như vậy để lưu một vòng tròn vào máy chủ.

UPDATE: Sau khi đọc lại RFC, tôi vẫn nghĩ rằng một không tồn "4xx + 303 Found" mã nên là chính xác. Tuy nhiên, "Xung đột 409" là mã câu trả lời tốt nhất hiện có (được chỉ ra bởi @Wrikken), có thể bao gồm một tiêu đề Vị trí chỉ vào tài nguyên hiện có.

Tôi không nghĩ bạn nên làm điều này.

POST, như bạn biết, để sửa đổi bộ sưu tập và nó được sử dụng để TẠO một mục mới. Vì vậy, nếu bạn gửi id (tôi nghĩ đó không phải là ý hay), bạn nên sửa đổi bộ sưu tập, nghĩa là sửa đổi mục, nhưng thật khó hiểu.

Sử dụng nó để thêm một mục, không có id. Đó là cách thực hành tốt nhất.

Nếu bạn muốn nắm bắt một ràng buộc ĐỘC ĐÁO (không phải id), bạn có thể trả lời 409, như bạn có thể làm trong các yêu cầu PUT. Nhưng không phải ID.

Tôi sẽ đi cùng 422 Unprocessable Entity, được sử dụng khi một yêu cầu không hợp lệ nhưng vấn đề không nằm ở cú pháp hoặc xác thực.

Là một đối số chống lại các câu trả lời khác, để sử dụng bất kỳ 4xxmã không lỗi nào sẽ ngụ ý đó không phải là lỗi của khách hàng và rõ ràng là như vậy. Để sử dụng 4xxmã không lỗi để biểu thị lỗi máy khách, không có nghĩa lý gì cả.

Có vẻ như 409 Conflict là câu trả lời phổ biến nhất ở đây, nhưng, theo thông số kỹ thuật, ngụ ý rằng tài nguyên đã tồn tại và dữ liệu mới mà bạn đang áp dụng cho nó không tương thích với trạng thái hiện tại của nó. Nếu bạn đang gửi mộtPOSTyêu cầu, ví dụ, với tên người dùng đã được sử dụng, nó không thực sự mâu thuẫn với tài nguyên đích, vì tài nguyên đích (tài nguyên bạn đang cố gắng tạo) chưa được đăng. Đó là lỗi đặc biệt đối với kiểm soát phiên bản, khi có xung đột giữa phiên bản tài nguyên được lưu trữ và phiên bản của tài nguyên được yêu cầu. Nó rất hữu ích cho mục đích đó, ví dụ như khi máy khách đã lưu trữ một phiên bản cũ của tài nguyên và gửi yêu cầu dựa trên phiên bản không chính xác đó sẽ không còn hợp lệ. "Trong trường hợp này, đại diện phản hồi có thể sẽ chứa thông tin hữu ích cho việc hợp nhất các khác biệt dựa trên lịch sử sửa đổi." Yêu cầu tạo một người dùng khác với tên người dùng đó là không thể xử lý được, không liên quan gì đến kiểm soát phiên bản.

Đối với bản ghi, 422 cũng là mã trạng thái mà GitHub sử dụng khi bạn cố gắng tạo một kho lưu trữ theo tên đã được sử dụng.

Tôi nghĩ đối với REST, bạn chỉ cần đưa ra quyết định về hành vi cho hệ thống cụ thể đó, trong trường hợp đó, tôi nghĩ câu trả lời "đúng" sẽ là một trong những câu trả lời được đưa ra ở đây. Nếu bạn muốn yêu cầu dừng lại và hành xử như thể khách hàng đã mắc lỗi cần khắc phục trước khi tiếp tục, thì hãy sử dụng 409. Nếu xung đột thực sự không quan trọng và muốn tiếp tục yêu cầu, hãy phản hồi bằng cách chuyển hướng khách hàng đến thực thể đã được tìm thấy. Tôi nghĩ rằng các API REST thích hợp nên được chuyển hướng (hoặc ít nhất là cung cấp tiêu đề vị trí) đến điểm cuối GET cho tài nguyên đó sau POST, vì vậy hành vi này sẽ mang lại trải nghiệm nhất quán.

EDIT: Điều đáng chú ý là bạn nên xem xét PUT vì bạn đang cung cấp ID. Sau đó, hành vi rất đơn giản: "Tôi không quan tâm những gì ở đó ngay bây giờ, hãy đặt thứ này ở đó." Có nghĩa là, nếu không có gì ở đó, nó sẽ được tạo ra; nếu có cái gì đó nó sẽ được thay thế. Tôi nghĩ rằng POST phù hợp hơn khi máy chủ quản lý ID đó. Việc tách hai khái niệm về cơ bản cho bạn biết cách xử lý nó (ví dụ PUT là idempotent để nó luôn hoạt động miễn là tải trọng xác thực, POST luôn tạo, do đó, nếu có xung đột ID, thì 409 sẽ mô tả xung đột đó) .

Một điều trị tiềm năng khác là sử dụng PATCH sau khi tất cả. Một PATCH được định nghĩa là một cái gì đó thay đổi trạng thái nội bộ và không bị hạn chế để nối thêm.

PATCH sẽ giải quyết vấn đề bằng cách cho phép bạn cập nhật các mục đã có. Xem: RFC 5789: VÒI

Tại sao không phải là 202 Chấp nhận ? Đó là một yêu cầu OK (200 giây), không có lỗi máy khách (400 giây), mỗi giây.

Từ 10 định nghĩa mã trạng thái :

"202 Được chấp nhận. Yêu cầu đã được chấp nhận để xử lý, nhưng quá trình xử lý chưa được hoàn thành."

... bởi vì nó không cần phải hoàn thành, bởi vì nó đã tồn tại. Khách hàng không biết nó đã tồn tại, họ không làm gì sai cả.

Tôi đang dựa vào việc ném 202 và trả lại nội dung tương tự với những gì GET /{resource}/{id}sẽ trả lại.

Tình cờ gặp phải câu hỏi này trong khi kiểm tra mã chính xác cho bản ghi trùng lặp.

Xin tha thứ cho sự thiếu hiểu biết của tôi nhưng tôi không hiểu tại sao mọi người lại bỏ qua mã "300" có ghi rõ "nhiều lựa chọn" hoặc "mơ hồ"

Theo tôi đây sẽ là mã hoàn hảo để xây dựng một hệ thống không chuẩn hoặc cụ thể cho mục đích sử dụng của riêng bạn. Tôi cũng có thể sai!

https://tools.ietf.org/html/rfc7231#section-6.4.1

Nhiều khả năng nó là 400 Bad Request

6.5.1. 400 yêu cầu xấu

Mã trạng thái 400 (Yêu cầu xấu) chỉ ra rằng máy chủ không thể hoặc sẽ không xử lý yêu cầu do lỗi được coi là lỗi máy khách (ví dụ: cú pháp yêu cầu không đúng định dạng, đóng khung thông báo yêu cầu không hợp lệ hoặc định tuyến yêu cầu lừa đảo).

Vì yêu cầu chứa giá trị trùng lặp (giá trị đã tồn tại), nên nó có thể được coi là lỗi máy khách. Cần thay đổi yêu cầu trước lần thử tiếp theo.
Bằng cách xem xét những sự thật này, chúng tôi có thể kết luận là Yêu cầu xấu HTTP STATUS 400.

Điều gì về 208 - http://httpstatusdogs.com/208-al yet - report ? Đó có phải là một lựa chọn?

Theo tôi, nếu điều duy nhất là tài nguyên lặp lại thì không có lỗi nào được nêu ra. Rốt cuộc, không có lỗi nào ở phía máy khách hay máy chủ.

Trong trường hợp của bạn, bạn có thể sử dụng 409 Conflict

Và nếu bạn muốn kiểm tra một HTTPsmã trạng thái khác từ danh sách bên dưới

Thông tin 1 ×

100 Continue
101 Switching Protocols
102 Processing

Thành công 2 ×

200 OK
201 Created
202 Accepted
203 Non-authoritative Information
204 No Content
205 Reset Content
206 Partial Content
207 Multi-Status
208 Already Reported
226 IM Used

Chuyển hướng 3 ×

300 Multiple Choices
301 Moved Permanently
302 Found
303 See Other
304 Not Modified
305 Use Proxy
307 Temporary Redirect
308 Permanent Redirect

Lỗi máy khách 4 ×

400 Bad Request
401 Unauthorized
402 Payment Required
403 Forbidden
404 Not Found
405 Method Not Allowed
406 Not Acceptable
407 Proxy Authentication Required
408 Request Timeout
409 Conflict
410 Gone
411 Length Required
412 Precondition Failed
413 Payload Too Large
414 Request-URI Too Long
415 Unsupported Media Type
416 Requested Range Not Satisfiable
417 Expectation Failed
418 I’m a teapot
421 Misdirected Request
422 Unprocessable Entity
423 Locked
424 Failed Dependency
426 Upgrade Required
428 Precondition Required
429 Too Many Requests
431 Request Header Fields Too Large
444 Connection Closed Without Response
451 Unavailable For Legal Reasons
499 Client Closed Request

Lỗi máy chủ 5 ×

500 Internal Server Error
501 Not Implemented
502 Bad Gateway
503 Service Unavailable
504 Gateway Timeout
505 HTTP Version Not Supported
506 Variant Also Negotiates
507 Insufficient Storage
508 Loop Detected
510 Not Extended
511 Network Authentication Required
599 Network Connect Timeout Error