Re: HTTP Response Codes - Just for clarity

Inline.

On Tue Nov 11 2014 at 3:52:59 PM David Burns <dburns@mozilla.com> wrote:

> Answers inline
>
> On 10/11/2014 09:51, James Graham 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.
>
> I was trying to show that if we don't find the attribute/property name
> we return a 404. The spec describes that if we can't find the
> attribute/property we need to return a null. I am happy to have that
> localends just infer that when they get back a 404 that it is the
> equivalent to a null.
>

HTTP 404 implies an error. If we go this route (and I don't think we
should), we should use a 204.


>
>
> >
> >> 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).
>
> Yea, we should be returning 405 if we expect a GET and get a POST or
> <insert other verb here>.
> What should we return if the URL and verb used are correct but the
> element is not found?
>
> 200 with current status (kinda like what we do oyrselves
>

We shouldn't use HTTP codes for command results - we'll lose the ability to
return errors about the request.  Stick to convention on response codes:

5xx: server failed to process the request
4xx: invalid request (404 - session/element id not found, 405 method not
permitted, etc.)
2xx: valid request & command executed successfully, see body for result


>
> >
> >> 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?
>
> I have a patch for this mostly done but would like to sort the data
> modelling first because it will make reading it easier (at least in my
> head)
>
>
>