Re: HTTP Response Codes - Just for clarity

On 12/11/14 17:27, Jason Leyba wrote:
  result
> 
>     I can't tell whether I agree with this, but I don't see any reason why
>     we can't send a response body containing error details with non-2xx
>     responses (indeed it seems to be a SHOULD-level requirement in HTTP). So
>     I'm not sure I see what ability you are worried about losing.
> 
> 
> Suppose we use REST and you request an element attribute:
> 
> GET /session/{sessionId}/element/{ELEMENT}/attribute/{name}
> 
> You get back a 404. What does the 404 apply to? {sessionId}, {ELEMENT},
> or {name}? In terms of the existing client APIs [1], the first two would
> be errors, but the third would be permissible. So how do you
> differentiate - put the details in the response body?
> 
> {"status": "session not found"}
> {"status": "element not found"}
> {"status": "success", "value": "null}
> 
> Now returning the 404 is redundant with the information in the response
> body.

I'm confused. It seems to me you just explained exactly why that's *not*
redundant. The 404 tells you that there was an error. The body tells you
what the error was. That's how HTTP is supposed to work.

What *is* redundant is putting a "status" field in 200 responses. They
are, by definition, all success responses.

Received on Wednesday, 12 November 2014 18:21:53 UTC