7

我正在构建一个网络服务，在这种特殊情况下，它用于询问有关顾客的信息。

假设，为了争论，查找网络命中是：

GET /patrons/619 HTTP/1.1

如果找到赞助人，我返回代码 200：

HTTP/1.1 200 OK

如果您省略或提供不是数字的帐号，我将返回 400。例如以下错误请求：

GET /patrons HTTP/1.1
GET /patrons/ HTTP/1.1
GET /patrons/qwerty HTTP/1.1
GET /patrons/kylie%20guenin HTTP/1.1

全部返回错误 400（错误请求），例如：

HTTP/1.1 400 Invalid patron number

我想有一个未找到赞助人的状态代码，作为 HTTP 状态代码返回。例如：

GET /patrons/1322 HTTP/1.1

HTTP/1.1 404 Not Found

我考虑过使用404 (Not Found)，这是一个有效的响应（所请求的资源，真的，真的，没有找到。）但我担心调试它的人可能会认为这意味着他们拼写/patrons/错误。

谁能想到我可以使用的另一个http状态码？

更新：我目不转睛

204 No Content 
The server successfully processed the request, but is not returning any content.

你说什么？

不要忘记，并非所有 HTTP 服务器都提供 HTML 内容。如果 IIS Web 服务器被要求提供一个名为：

GET /MyStartPage.html HTTP/1.1

然后 HTTP 服务器必须决定响应什么。在大多数 Web 服务器上，名为/MyStartPage.html的资源对应于位于硬盘驱动器上的文件。

而 StackOverflow 可以：

GET /posts/1027301 HTTP/1.1

其中，如果该资源不存在，则 Web 服务器应该（正确地）返回 404。

4

9 回答 9

17

404 Not Found is the correct thing to return, if it's a service, it's not really being used by humans but by machines, and therefore, typos, shouldn't be your first concern.

Also, there's very little you're going to be able to do to counter human behavior anyway (thinking one thing when it's really another). If you're returning a little error msg as part of the error code, everything should work out. You could even suggest to them a possible fix.

Returning a 500 when the application is doing exactly what it's designed to do also seems a little odd. 404 describes exactly the situation: Resource not found.

于 2009-06-22T13:51:49.467 回答
7

I think you should use 404. Developers of the API will understand what 404 means and will therefore follow there own usual debugging process in order to resolve the problem. Stick to the protocol.

于 2009-06-22T13:55:59.660 回答
6

Error 404 is actually a more acceptable response for this case, because the resource truly is not found. You could always have a custom error document that explains that it is the Patron ID that is not found.

A 400 error implies that the client sent malformed syntax, which is not the case in your example. Thus, you should not use this error code. It may seem that "Bad Request" is accurate, but what this actually means is there's an error in the request header syntax.

This is also not a 500 error because no error has occurred. There is no problem with the web server fulfilling the request, the fact is that the request is seeking a resource that is not present.

404 is the only appropriate response, unless you want to consider it a fully valid request, return status 200 and a page explaining that the requested Patron does not exist.

From my original comment on the question:

I don't think that a 200-level error would be appropriate either, consider the explanations at W3 w3.org/Protocols/rfc2616/rfc2616-sec10.html

于 2009-06-22T13:55:49.957 回答
5

IMHO, the HTTP response is not the proper place to handle this, as the error is not at the HTTP level. It's at the application level. One possible solution is to use the Null Object Pattern to return a null 'Patron' that conforms to the Patron interface, but indicates that no such person exists.

UPDATE: I've been convinced that this answer is wrong. However, I want to leave it up, as it is a potentially valid answer (depending on details not presented in the question), and I think the comments are instructive.

于 2009-06-22T13:51:21.930 回答
2

Typically if your service encounters an error that it is unable to handle, but the request is well formed, then I would think you would want to return a 500 status code.

Also, another reason why I say 500 would be appropriate is that from my experience in .NET web services, whenever I throw an exception across the wire (such as a RecordNotFound exception), the web server and client have always interpretted the response to be a 500 status code.

Either way, it would be a good idea to review this list of http status codes, and fine the one that suites your needs the best.

于 2009-06-22T13:52:06.173 回答
1

It depends on which kind of webservice you're constructing.

SOAP and XML webservices typically return 200 OK if a requested object (patron) cannot be found and encode the error type/message/description into the response document. They separate a transport level (HTTP) from the messages exchanged (XML). A 404 error (which is on the transport level) is returned only, if you request a non-existing API endpoint (wrong URL).

With a REST webservice however, you use HTTP methods and statuses directly for message exchange. REST uses different HTTP methods (GET/POST/PUT/DELETE) to specify which action is wanted and the server returns the status as the HTTP status. So in case of a REST webservice, 404 would be the proper HTTP status if a patron could not be found.

500 is inappropriate in any case I think, since 5xx means that there's been something wrong on the serverside (which isn't the case) while 4xx errors mean that there's something wrong on the client side.

于 2009-06-22T14:19:27.710 回答
1

It may be 4 years old but it is still pretty relevant. For APIs which are to be used by both borwsers and native apps, I find it is much simpler to use the HTTP codes for status indication. And if necessary use a couple of extra codes from the unallocated ones for conditions that don't have a good fit to existing HTTP codes.

于 2013-11-05T14:31:30.077 回答
0

Errors at the web service level should not just return a simple HTTP status line, but should instead return content in a valid and documented format that can be parsed by the client accessing your service. The returned document should contain an error code that is part of a documented set of codes specific to your web service, as well as a short description of the problem and optionally a more detailed description of the problem.

于 2009-06-22T14:12:46.380 回答
0

If you want to control the web service's responses via HTTP response codes, then you could indeed use a 404 to indicate this condition.

However, I would think it's more natural to have the web service's response defined entirely in the body of the HTTP response, and just return 200 for a successful communication ("I understood your request and have sent you an appropriate response"). In this case then, you'd return 200 as normal with the payload of your request (XML or JSON or whatever) indicating that no matching entity was found

I'd consider non-200 error codes similar to exceptions in conventional programming languages, and the HTTP response body more like the return code. Imagine if you were implementing this conventionally - would you throw an exception if no entity was found, or return null? Personally, given the fragile nature of network connections, I would want to reserve all HTTP-level error codes for problems in communication, and I'd much rather always return 200 OK from the service itself, along with a payload specifying the result or any service-level error.

于 2009-06-22T14:51:11.017 回答