Josh Kelley
Josh Kelley

Reputation: 58352

REST response code for accessing a corrupt/invalid resource

What's the best HTTP status code to use in response to an HTTP GET for a resource that's corrupt or semantically invalid?

E.g., consider a request to GET /person/1234 where data for person ID 1234 exists on the server but violates some business rule, so the server refuses to use it.

Any suggestions?

Upvotes: 4

Views: 2780

Answers (2)

Salem Ouerdani
Salem Ouerdani

Reputation: 7886

according to iana.org:

4xx: Client Error - The request contains bad syntax or cannot be fulfilled
5xx: Server Error - The server failed to fulfill an apparently valid request

I think none of the 4xx status code should be valid as a response to an internal server error or migration or ... where client has no responsibilities or where user's inputs are expected to be rechecked. unless user's pre-filled data are involved like maybe user's package is not allowing him to access that data after a pre-determinate and known date, in such specific case It may be valid a 403 Forbidden as @Bari did suggest.

I'm not an expert but I think when the rejection or the decision of considering endpoint data as corrupt or invalid is made by server, then it will depends on what should be done next. I see 3 possible cases:

1. It is expected that somehow this is going to be fixed and client should be invited to request it back but at some future moment ==> 503 (Service Unavailable):

503 (Service Unavailable) 

   status code indicates that the server
   is currently unable to handle the request due to a temporary overload
   or scheduled maintenance, which will likely be alleviated after some
   delay.  The server MAY send a Retry-After header field
   (Section 7.1.3) to suggest an appropriate amount of time for the
   client to wait before retrying the request.

2. Something is wrong, it is not client responsibility but there is an alternative way to access data, maybe following a specific process or sending further details ==> 510 Not Extended

2. Server cannot fulfill the request but there is an alternative way that requires it to include further details. Example: when requested data is corrupt, server error response may include a list of older (or unsaved, unversioned) versions of it and expect client to be more specific about which version to select so it could be fetched instead of the corrupted one ==> 510 Not Extended

510 Not Extended

   The policy for accessing the resource has not been met in the
   request.  The server should send back all the information necessary
   for the client to issue an extended request. It is outside the scope
   of this specification to specify how the extensions inform the
   client.

   If the 510 response contains information about extensions that were
   not present in the initial request then the client MAY repeat the
   request if it has reason to believe it can fulfill the extension
   policy by modifying the request according to the information provided
   in the 510 response. Otherwise the client MAY present any entity
   included in the 510 response to the user, since that entity may
   include relevant diagnostic information.
  • case 2 was updated to include an example as IMHO it may fit in such case. but again I'm not any expert and I may be wrong about it

3. No alternative ways, nothing to be expected or none of the other cases ==> 500 should be good

500 (Internal Server Error) 

   status code indicates that the server
   encountered an unexpected condition that prevented it from fulfilling
   the request.

Upvotes: 0

Josh Kelley
Josh Kelley

Reputation: 58352

After reading the comments and the linked resources, it looks like @RemyLebeau's approach is best:

I think 500 is the only official response code that fits this situation. And there is nothing stopping you from including a response body that describes the reason for the failure.

Upvotes: 1

Related Questions