CODEWITHSUNDEEP
httprest
Jesvin Jose
Jesvin Jose

Reputation: 23078

HTTP response codes to distinguish between improper parameters and failing values

What are suitable response codes and messages for:

  1. fields submitted the wrong way (URL parameters vs body) or missing fields
  2. fields getting invalid values (string instead of numbers, timestamp in future)
  3. some characters like ?, / break stuff in URL parameters
  4. Actual failures: invalid credentials, repeating already-done action

At present, we use 400 for all.

Upvotes: 6

Views: 5803

Answers (2)

fumanchu
fumanchu

Reputation: 14559

Read the HTTP spec for each response code to get some information about what to return in the response body. 4xx, for example, says "Except when responding to a HEAD request, the server SHOULD include a representation containing an explanation of the error situation, and whether it is a temporary or permanent condition."

The primary point to keep in mind is that the HTTP response codes are designed to be uniform, and therefore have much more to do with fostering interoperability than feeding the detailed needs of individual applications. Use the response body, not the code, to include minute details in a format that you expect your clients to understand.

1 fields submitted the wrong way (URL parameters vs body) or missing fields

Return "404 Not Found". Querystring parameters are part of the URI and are used to identify a resource. /foo/bar?a=1&b=2 identifies a different resource than foo/bar. If the resource does not exist, return 404. It does not matter that the same logic in your code is used to handle any querystring parameters for the same path: those details are intentionally hidden behind the uniform interface. See the URI spec for more details.

2 fields getting invalid values (string instead of numbers, timestamp in future)

400 is best here, unless the resource is in a state which conflicts with the request that the user might reasonably be able to resolve (and then resubmit the request), in which case return 409.

3 some characters like ?, / break stuff in URL parameters

If such breakage is due to your server not correctly handling reserved characters in the querystring component, return 500. If the client submitted a malformed Request-URI, return 400. If the URI identifies a resource which your server does not handle, return 404.

4 Actual failures: invalid credentials, repeating already-done action

Invalid credentials should result in "401 Unauthorized". Repeating an action that has already been done should result in 200 OK (or a redirect, etc) if the request method is idempotent (GET, HEAD, PUT, DELETE). For POST, repeating an action depends entirely on the nature of the action, and practically any status code may be returned. 400/409 is common, but many such resources simply perform the action again, which is often desirable.

Upvotes: 3

ArjunShankar
ArjunShankar

Reputation: 23670

Cases 1, 2 and 3 in your question are essentially syntactic errors in the request

=> 400 Bad Request

(RFC 2616 says: The request could not be understood by the server due to malformed syntax.)

As to case 4:

a. Invalid credentials

=> 401 Unauthorized

b. Repeating already-done action

=> 403 Forbidden

(The RFC says: The server understood the request, but is refusing to fulfill it. Authorization will not help and the request SHOULD NOT be repeated.)

But then 409 Conflict and 410 Gone make sense when trying to modify stuff incorrectly (PUT) or accessing resources already deleted, respectively.

And here is RFC 2616 Section 10.

Upvotes: 6

Related Questions