Re: HTTP Response Codes - Just for clarity

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.


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

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

Received on Tuesday, 11 November 2014 23:52:53 UTC