Phản hồi 400 so với 422 đối với POST dữ liệu

Tôi đang cố gắng tìm ra mã trạng thái chính xác để trả về các kịch bản khác nhau với API "giống như REST" mà tôi đang làm việc. Giả sử tôi có một điểm cuối cho phép POST mua hàng ở định dạng JSON. Nó trông như thế này:

{
    "account_number": 45645511,
    "upc": "00490000486",
    "price": 1.00,
    "tax": 0.08
}

Tôi nên trả lại những gì nếu khách hàng gửi cho tôi "sales_tax" (thay vì "thuế" dự kiến). Hiện tại, tôi đang trả lại 400. Nhưng, tôi đã bắt đầu tự đặt câu hỏi về điều này. Tôi có nên thực sự trở lại một 422? Ý tôi là, đó là JSON (được hỗ trợ) và JSON hợp lệ, nó chỉ không chứa tất cả các trường bắt buộc.

400 Yêu cầu Không hợp lệ dường như là mã trạng thái HTTP / 1.1 tốt nhất cho trường hợp sử dụng của bạn.

Tại thời điểm câu hỏi của bạn (và câu trả lời ban đầu của tôi), RFC 7231 không phải là một điều; tại thời điểm đó tôi đã phản đối 400 Bad Requestvì RFC 2616 đã nói (với sự nhấn mạnh của tôi):

Máy chủ không thể hiểu được yêu cầu do cú pháp không đúng .

và yêu cầu bạn mô tả là JSON hợp lệ về mặt cú pháp được bao bọc trong HTTP có hiệu lực về mặt cú pháp và do đó máy chủ không có vấn đề gì với cú pháp của yêu cầu.

Tuy nhiên, như Lee Saferite đã chỉ ra trong các bình luận , RFC 7231, đã lỗi thời RFC 2616, không bao gồm hạn chế đó :

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).

Tuy nhiên, trước khi diễn đạt lại (hoặc nếu bạn muốn ngụy biện về RFC 7231 chỉ là một tiêu chuẩn được đề xuất ngay bây giờ), 422 Unprocessable Entitydường như không phải là mã trạng thái HTTP không chính xác cho trường hợp sử dụng của bạn, bởi vì như giới thiệu về RFC 4918 nói:

Mặc dù các mã trạng thái được cung cấp bởi HTTP / 1.1 là đủ để mô tả hầu hết các điều kiện lỗi mà các phương thức WebDAV gặp phải, có một số lỗi không nằm gọn trong các danh mục hiện có. Đặc tả này xác định các mã trạng thái bổ sung được phát triển cho các phương thức WebDAV (Phần 11)

Và mô tả về422 nói:

Mã trạng thái 422 (Thực thể không thể xử lý) có nghĩa là máy chủ hiểu loại nội dung của thực thể yêu cầu (do đó mã trạng thái 415 (Loại phương tiện không được hỗ trợ) là không phù hợp) và cú pháp của thực thể yêu cầu là chính xác (do đó là 400 (Yêu cầu sai ) mã trạng thái không phù hợp) nhưng không thể xử lý các hướng dẫn có trong đó.

(Lưu ý tham chiếu đến cú pháp; Tôi nghi ngờ 7231 cũng bị lỗi thời 4918)

Âm thanh này chính xác như tình hình của bạn, nhưng chỉ trong trường hợp có bất kỳ nghi ngờ gì nữa, nó tiếp tục nói:

Ví dụ, điều kiện lỗi này có thể xảy ra nếu một thân yêu cầu XML chứa các hướng dẫn XML được định dạng đúng (nghĩa là đúng về mặt cú pháp), nhưng sai về mặt ngữ nghĩa, về mặt ngữ nghĩa.

(Thay thế "XML" bằng "JSON" và tôi nghĩ chúng ta có thể đồng ý rằng đó là tình huống của bạn)

Bây giờ, một số người sẽ phản đối rằng RFC 4918 nói về "Phần mở rộng HTTP cho Tác giả và Phiên bản phân tán Web (WebDAV)" và bạn (có lẽ) không làm gì liên quan đến WebDAV vì vậy không nên sử dụng những thứ từ nó.

Đưa ra lựa chọn giữa việc sử dụng mã lỗi trong tiêu chuẩn ban đầu rõ ràng không bao gồm tình huống và một từ một phần mở rộng mô tả chính xác tình huống, tôi sẽ chọn cái sau.

Hơn nữa, RFC 4918 Mục 21.4 đề cập đến Sổ đăng ký mã trạng thái giao thức truyền siêu văn bản (HTTP) IANA , nơi có thể tìm thấy 422.

Tôi đề nghị rằng việc khách hàng hoặc máy chủ HTTP sử dụng bất kỳ mã trạng thái nào từ sổ đăng ký đó là hoàn toàn hợp lý, miễn là họ làm như vậy một cách chính xác.

Nhưng kể từ HTTP / 1.1, RFC 7231 có lực kéo, vì vậy chỉ cần sử dụng 400 Bad Request!

400 Yêu cầu xấu là mã trạng thái HTTP thích hợp cho trường hợp sử dụng của bạn. Mã được xác định bởi HTTP / 0.9-1.1 RFC.

Máy chủ không thể hiểu được yêu cầu do cú pháp không đúng. Khách hàng KHÔNG NÊN lặp lại yêu cầu mà không sửa đổi.

http://tools.ietf.org/html/rfc2616#section-10.4.1

Thực thể không thể xử lý được xác định bởi RFC 4918 - WebDav. Lưu ý rằng có một chút khác biệt so với 400, xem văn bản được trích dẫn dưới đây.

Điều kiện lỗi này có thể xảy ra nếu một thân yêu cầu XML chứa các hướng dẫn XML được định dạng đúng (nghĩa là đúng về mặt cú pháp), nhưng sai về mặt ngữ nghĩa, về mặt ngữ nghĩa.

Để giữ giao diện thống nhất, bạn chỉ nên sử dụng 422 trong trường hợp phản hồi XML và bạn cũng nên hỗ trợ tất cả các mã trạng thái được xác định bởi tiện ích mở rộng Webdav, không chỉ là 422.

http://tools.ietf.org/html/rfc4918#page-78

Xem thêm bài viết của Mark Nottingham về mã trạng thái:

thật sai lầm khi cố gắng ánh xạ từng phần trong ứng dụng của bạn sâu vào các mã trạng thái HTTP; trong hầu hết các trường hợp, mức độ chi tiết mà bạn muốn hướng tới là thô hơn nhiều. Khi nghi ngờ, bạn có thể sử dụng các mã trạng thái chung 200 OK, 400 Yêu cầu Không hợp lệ và 500 Lỗi Dịch vụ Nội bộ khi không phù hợp hơn .

Cách nghĩ về mã trạng thái HTTP

Để phản ánh tình trạng của năm 2015:

Về mặt hành vi, cả hai mã phản hồi 400 và 422 sẽ được đối xử giống nhau bởi các khách hàng và trung gian, vì vậy nó thực sự không tạo ra sự khác biệt cụ thể mà bạn sử dụng.

Tuy nhiên, tôi hy vọng sẽ thấy 400 hiện đang được sử dụng rộng rãi hơn và hơn nữa các giải thích mà thông số HTTPbis cung cấp làm cho nó phù hợp hơn trong hai mã trạng thái:

• Thông số HTTPbis làm rõ ý định 400 không chỉ dành cho các lỗi cú pháp. Cụm từ rộng hơn "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" hiện được sử dụng.
• 422 Cụ thể là một phần mở rộng WebDAV và không được tham chiếu trong RFC 2616 hoặc trong đặc tả HTTPbis mới hơn .

Đối với ngữ cảnh, HTTPbis là bản sửa đổi của thông số HTTP / 1.1 cố gắng làm rõ các khu vực không rõ ràng hoặc không nhất quán. Khi nó đã đạt đến trạng thái được phê duyệt, nó sẽ thay thế RFC2616.

Nghiên cứu điển hình: API GitHub

https://developer.github.com/v3/#client-errors

Có lẽ sao chép từ các API nổi tiếng là một ý tưởng khôn ngoan:

Có ba loại lỗi máy khách có thể xảy ra đối với các lệnh gọi API nhận nội dung yêu cầu:

Gửi JSON không hợp lệ sẽ dẫn đến phản hồi 400 Yêu cầu Không hợp lệ.

HTTP/1.1 400 Bad Request
Content-Length: 35

{"message":"Problems parsing JSON"}

Gửi sai loại giá trị JSON sẽ dẫn đến phản hồi 400 Yêu cầu Không hợp lệ.

HTTP/1.1 400 Bad Request
Content-Length: 40

{"message":"Body should be a JSON object"}

Gửi các trường không hợp lệ sẽ dẫn đến phản hồi Thực thể không thể xử lý 422.

HTTP/1.1 422 Unprocessable Entity
Content-Length: 149

{
  "message": "Validation Failed",
  "errors": [
    {
      "resource": "Issue",
      "field": "title",
      "code": "missing_field"
    }
  ]
}

Không có câu trả lời đúng, vì nó phụ thuộc vào định nghĩa của "cú pháp" là gì đối với yêu cầu của bạn. Điều quan trọng nhất là bạn:

1. Sử dụng (các) mã phản hồi nhất quán
2. Bao gồm càng nhiều thông tin bổ sung trong phần phản hồi càng tốt để giúp nhà phát triển sử dụng API của bạn tìm hiểu điều gì đang xảy ra. =

Trước khi tất cả mọi người nhảy lên tôi vì nói rằng không có câu trả lời đúng hay sai ở đây, hãy để tôi giải thích một chút về cách tôi đi đến kết luận.

Trong ví dụ cụ thể này, câu hỏi của OP là về một yêu cầu JSON chứa khóa khác với dự kiến. Bây giờ, tên khóa nhận được rất giống nhau, từ quan điểm ngôn ngữ tự nhiên, đến khóa dự kiến, nhưng, đúng, khác, và do đó không (thường) được máy nhận ra là tương đương.

Như tôi đã nói ở trên, yếu tố quyết định là cú pháp có nghĩa là gì . Nếu yêu cầu được gửi với Loại nội dung application/json, thì có, yêu cầu đó có hiệu lực về mặt cú pháp vì đó là cú pháp JSON hợp lệ, nhưng không hợp lệ về mặt ngữ nghĩa , vì nó không phù hợp với những gì mong đợi. (giả sử một định nghĩa chặt chẽ về những gì làm cho yêu cầu trong câu hỏi có giá trị về mặt ngữ nghĩa hay không).

Mặt khác, nếu yêu cầu được gửi với Loại Nội dung tùy chỉnh cụ thể hơn như application/vnd.mycorp.mydatatype+jsonvậy, có lẽ, chỉ định chính xác các trường được mong đợi, thì tôi sẽ nói rằng yêu cầu có thể dễ dàng bị vô hiệu hóa về mặt cú pháp, do đó phản hồi 400.

Trong trường hợp được đề cập, vì khóa bị sai, không phải giá trị , đã xảy ra lỗi cú pháp nếu có thông số kỹ thuật cho các khóa hợp lệ là gì. Nếu không có thông số kỹ thuật cho các khóa hợp lệ hoặc lỗi xảy ra với một giá trị , thì đó sẽ là một lỗi ngữ nghĩa .

Giải thích về thực thể không thể xử lý được cập nhật: ngày 6 tháng 3 năm 2017

422 thực thể không thể xử lý là gì?

Mã trạng thái 422 xảy ra khi một yêu cầu được hình thành tốt, tuy nhiên, do lỗi ngữ nghĩa, nó không thể được xử lý. Trạng thái HTTP này được giới thiệu trong RFC 4918 và đặc biệt hướng đến các tiện ích mở rộng HTTP cho Tác giả và Phiên bản phân tán Web (WebDAV).

Có một số tranh cãi ngoài kia về việc liệu các nhà phát triển có nên trả lại lỗi 400 so với 422 cho khách hàng hay không (nhiều hơn về sự khác biệt giữa cả hai trạng thái bên dưới). Tuy nhiên, trong hầu hết các trường hợp, người ta đồng ý rằng trạng thái 422 chỉ nên được trả về nếu bạn hỗ trợ các khả năng của WebDAV.

Một định nghĩa từng từ của mã trạng thái 422 được lấy từ phần 11.2 trong RFC 4918 có thể được đọc dưới đây.

Mã trạng thái 422 (Thực thể không thể xử lý) có nghĩa là máy chủ hiểu loại nội dung của thực thể yêu cầu (do đó mã trạng thái 415 (Loại phương tiện không được hỗ trợ) là không phù hợp) và cú pháp của thực thể yêu cầu là chính xác (do đó là 400 (Yêu cầu sai ) mã trạng thái không phù hợp) nhưng không thể xử lý các hướng dẫn có trong đó.

Định nghĩa tiếp tục nói:

Ví dụ, điều kiện lỗi này có thể xảy ra nếu một thân yêu cầu XML chứa các hướng dẫn XML được định dạng đúng (nghĩa là đúng về mặt cú pháp), nhưng sai về mặt ngữ nghĩa, về mặt ngữ nghĩa.

Mã trạng thái 400 so với 422

Lỗi yêu cầu xấu sử dụng mã trạng thái 400 và phải được trả lại cho máy khách nếu cú ​​pháp yêu cầu không đúng, chứa khung tin nhắn yêu cầu không hợp lệ hoặc định tuyến yêu cầu lừa đảo. Mã trạng thái này có vẻ khá giống với trạng thái thực thể không thể xử lý 422, tuy nhiên, một thông tin nhỏ phân biệt chúng là thực tế rằng cú pháp của một thực thể yêu cầu đối với lỗi 422 là chính xác trong khi cú pháp của yêu cầu tạo ra 400 lỗi không chính xác.

Việc sử dụng trạng thái 422 chỉ nên dành riêng cho các trường hợp sử dụng rất cụ thể. Trong hầu hết các trường hợp khác xảy ra lỗi máy khách do cú pháp không đúng, nên sử dụng trạng thái Yêu cầu xấu 400.

https://www.keycdn.com/support/422-un Processable-entity /

Trường hợp của bạn: HTTP 400 là mã trạng thái phù hợp cho trường hợp của bạn từ phối cảnh REST vì nó không đúng về mặt cú pháp để gửi sales_taxthay vì tax, mặc dù đó là một JSON hợp lệ. Điều này thường được thi hành bởi hầu hết các khung công tác phía máy chủ khi ánh xạ JSON tới các đối tượng. Tuy nhiên, có một số triển khai REST bỏ qua mới keytrong đối tượng JSON. Trong trường hợp đó, một content-typeđặc tả tùy chỉnh để chỉ chấp nhận các trường hợp lệ có thể được thi hành bởi phía máy chủ.

Kịch bản lý tưởng cho 422:

Trong một thế giới lý tưởng, 422 được ưu tiên và thường được chấp nhận để gửi dưới dạng phản hồi nếu máy chủ hiểu loại nội dung của thực thể yêu cầu và cú pháp của thực thể yêu cầu là chính xác nhưng không thể xử lý dữ liệu vì lỗi ngữ nghĩa của nó.

Các tình huống của 400 trên 422:

Hãy nhớ rằng, mã phản hồi 422 là mã trạng thái HTTP (WebDAV) mở rộng. Vẫn còn một số ứng dụng khách / thư viện giao diện người dùng HTTP chưa sẵn sàng để xử lý 422. Đối với họ, đơn giản như "HTTP 422 là sai, vì đó không phải là HTTP" . Từ góc độ dịch vụ, 400 không khá cụ thể.

Trong kiến ​​trúc doanh nghiệp, các dịch vụ được triển khai chủ yếu trên các lớp dịch vụ như SOA, IDM, v.v. Chúng thường phục vụ nhiều máy khách khác nhau, từ máy khách gốc rất cũ đến máy khách HTTP mới nhất. Nếu một trong các máy khách không xử lý HTTP 422, các tùy chọn là yêu cầu khách hàng nâng cấp hoặc thay đổi mã phản hồi của bạn thành HTTP 400 cho mọi người. Theo kinh nghiệm của tôi, điều này rất hiếm trong những ngày này nhưng vẫn có khả năng. Vì vậy, một nghiên cứu cẩn thận về kiến ​​trúc của bạn luôn được yêu cầu trước khi quyết định mã phản hồi HTTP.

Để xử lý tình huống như vậy, các lớp dịch vụ thường sử dụng versioninghoặc cài đặt configurationcờ cho các máy khách tuân thủ HTTP nghiêm ngặt để gửi 400 và gửi 422 cho phần còn lại của chúng. Bằng cách đó, họ cung cấp hỗ trợ tương thích ngược cho người tiêu dùng hiện tại nhưng đồng thời cung cấp khả năng cho các khách hàng mới sử dụng HTTP 422.

Bản cập nhật mới nhất cho RFC7321 cho biết:

The 400 (Bad Request) status code indicates that the server cannot or
   will not process the request due to something that is perceived to be
   a client error (e.g., malformed request syntax, invalid request
   message framing, or deceptive request routing).

Điều này xác nhận rằng các máy chủ có thể gửi HTTP 400 cho yêu cầu không hợp lệ. 400 không chỉ đề cập đến lỗi cú pháp nữa , tuy nhiên, 422 vẫn là một phản hồi chính hãng miễn là khách hàng có thể xử lý nó.

Thứ nhất đây là một câu hỏi rất hay.

400 Yêu cầu Không hợp lệ - Khi thiếu thông tin quan trọng trong yêu cầu

ví dụ: Tiêu đề ủy quyền hoặc tiêu đề loại nội dung. Mà hoàn toàn được yêu cầu bởi máy chủ để hiểu yêu cầu. Điều này có thể khác nhau từ máy chủ đến máy chủ.

422 Thực thể không thể xử lý - Khi cơ thể yêu cầu không thể được phân tích cú pháp.

Điều này ít nghiêm trọng hơn 400. Yêu cầu đã đến máy chủ. Các máy chủ đã thừa nhận yêu cầu đã có cấu trúc cơ bản ngay. Nhưng thông tin trong phần yêu cầu không thể được phân tích hoặc hiểu.

ví dụ Content-Type: application/xmlkhi cơ thể yêu cầu là JSON.

Đây là một bài viết liệt kê mã trạng thái và việc sử dụng nó trong API REST. https://metamug.com/article/status-codes-for-rest-api.php

Bạn thực sự nên trả về "200 OK" và trong phần phản hồi có thông báo về những gì đã xảy ra với dữ liệu được đăng. Sau đó, tùy thuộc vào ứng dụng của bạn để hiểu thông điệp.

Vấn đề là, mã trạng thái HTTP chính xác là như vậy - mã trạng thái HTTP. Và chúng chỉ có ý nghĩa ở lớp vận chuyển, không phải ở lớp ứng dụng. Lớp ứng dụng thực sự thậm chí không bao giờ biết rằng HTTP đang được sử dụng. Nếu bạn đã chuyển lớp vận chuyển của mình từ HTTP sang Homing Pigeons, nó sẽ không ảnh hưởng đến lớp ứng dụng của bạn theo bất kỳ cách nào.

Hãy để tôi cung cấp cho bạn một ví dụ không ảo. Giả sử bạn yêu một cô gái và cô ấy yêu bạn nhưng gia đình cô ấy chuyển đến một đất nước hoàn toàn khác. Cô ấy cho bạn địa chỉ thư mới của cô ấy. Tự nhiên, bạn quyết định gửi cho cô ấy một bức thư tình. Vì vậy, bạn viết thư của bạn, đặt nó vào một phong bì, viết địa chỉ của cô ấy trên phong bì, đặt một con tem trên đó và gửi nó. Bây giờ hãy xem xét các kịch bản này

1. Bạn quên viết tên đường phố. Bạn sẽ nhận được một lá thư chưa mở trở lại với một thông báo viết trên đó nói rằng địa chỉ không đúng. Bạn làm hỏng yêu cầu và bưu điện nhận được không thể xử lý nó. Đó là tương đương với việc nhận "400 yêu cầu xấu".
2. Vì vậy, bạn sửa địa chỉ và gửi thư một lần nữa. Nhưng do một số điều xui xẻo, bạn đã viết sai tên của đường phố. Bạn sẽ nhận được thư một lần nữa với thông báo rằng địa chỉ không tồn tại. Điều đó tương đương với việc nhận "404 Không tìm thấy".
3. Bạn sửa lại địa chỉ và lần này bạn quản lý để viết địa chỉ chính xác. Cô gái của bạn nhận được thư và viết lại cho bạn. Nó tương đương với việc nhận "200 OK". Tuy nhiên, điều này không có nghĩa là bạn sẽ thích những gì cô ấy viết trong thư. Nó đơn giản có nghĩa là cô ấy đã nhận được tin nhắn của bạn và có phản hồi cho bạn. Cho đến khi bạn mở phong bì và đọc thư của cô ấy, bạn không thể biết cô ấy có nhớ bạn hay muốn chia tay với bạn không.

Nói tóm lại: Trả lại "200 OK" không có nghĩa là ứng dụng máy chủ có tin tốt cho bạn. Nó chỉ có nghĩa là nó có một số tin tức.

PS: Mã trạng thái 422 chỉ có ý nghĩa trong ngữ cảnh của WebDAV. Nếu bạn không làm việc với WebDAV, thì 422 có ý nghĩa tiêu chuẩn chính xác giống như bất kỳ mã không chuẩn nào khác = không có mã nào.