Re: HTTP Response Codes - Just for clarity

Oops, hit send.

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}
   405: valid command URL, but invalid method

POST /session/{sessionId}/element/
   200 {"status": "success", "value": {ELEMENT}}
   200 {"status": "no such element", "value": error-details}
   404: {sessionId} not found

Just to recap: use HTTP response code to communicate whether the request
was valid and could be executed. Put the actual details in the response
body.

On Mon Nov 10 2014 at 10:34:28 AM Jason Leyba <jleyba@google.com> wrote:

> 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?
>>
>>
>>