Re: HTTP Response Codes - Just for clarity

Why not just stick to HTTP convention:
200: valid request, executed successfully; details in JSON body
4xx: invalid client request
5xx: valid request, but server failed to execute it

Applied to your examples (and adding a few others):

GET /session/{sessionId}/element/{ELEMENT}/attribute/{name}
   200 if command finished; response has {"value": X} (X may be null)
   404 if {sessionId} or {ELEMENT} not valid references

POST /session/{sessionId}/element/{ELEMENT}/attribute/{name}


On Mon Nov 10 2014 at 1:51:41 AM James Graham <james@hoppipolla.co.uk>
wrote:

> On 08/11/14 00:44, David Burns wrote:
> > Hi All,
> >
> > I have started going through the notes and making some of the changes
> > and am looking at HTTP Response codes that should be returned. I have
> > put examples below, can you check that I am understanding correctly
> > before I carry on. This is only a subset but it covers most of the URL
> > endpoint types
> >
> > GET /session/{sessionId}/element/{ELEMENT}/attribute/{name}
> >   200 if the attribute found
> >   404 if not found with data being returned as {"value": null}
>
> I'm not sure why this would be {"value":null}; I thought the plan was
> for all non-200 responses to have {"error":something} in the body.
>
> >
> > POST /session/{sessionId}/element/
> >   200 if Element is found
> >   501 if it is not found with error in data model returned
>
> Assuming you mean this as an example of a method/path combo that doesn't
> exist, 404 seems more appropriate (and 405 if the path exists but the
> wrong method was used).
>
> > POST /session/{sessionId}/element/{ELEMENT}
> >   200 if Element is found
> >   404 if it is not found with error in data model returned
>
> I don't see this in the spec, so it seems like it would return 404?
>
>
>