Re: Proposed resolution for ISSUE-64 (status codes)

Gregg Kellogg
gregg@greggkellogg.net

On Jul 31, 2014, at 12:38 PM, Markus Lanthaler <markus.lanthaler@gmx.net> wrote:

> On 30 Jul 2014 at 13:25, Gregg Kellogg wrote:
>> On Jul 30, 2014, at 6:25 AM, Ruben Verborgh wrote:
>> 
>>> (Copied from another thread for clarity.)
>>> 
>>> ISSUE 64: Review HTTP status codes for non-existing / empty fragments
>>> The current spec says: 	. reply with status code 200 OK if the fragment
>>> (page) with the given URL exists and is non-empty, i.e., one or more
>>> triples match the selector; 	. reply with status code 404 Not Found if
>>> the fragment (page) with the given URL does not exist or is empty,
>>> i.e., no triples match the selector. 	. reply with status code 404 Not
>>> Found if the selector is invalid i.e., the parameter values are not in the domain of the selector. This is the case if, for instance, a literal is used as subject.
>>> However, it is argued that 404 might not be the best status code for all cases. 400 might be appropriate for invalid requests that will never have matches (i.e., literal as subject - case 3).
>> 
>> Does this imply that if LD Fragments are used for Hydra Collections that you could not
>> return an empty collection? Returning an empty collection would be useful for describing
>> operations, say, to add something to the collection.
> 
> No, it didn't imply that. A 404 can include a response body which means you
> can return an empty collection.

Not useful if you're using your API also as a website; A web browser won't act too kindly to a 404 response, even with a body, AFAIK. Also, there's a difference between trying to fetch an empty collection, and an undefined collection. It's for the undefined case that a 404 is most useful; arguably, this is true for pure LDF as well.

Gregg

> --
> Markus Lanthaler
> @markuslanthaler
> 
> 
> 
>

Received on Thursday, 31 July 2014 22:58:00 UTC