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

> -----Original Message-----
> From: Ruben Verborgh [mailto:ruben.verborgh@ugent.be]
> Sent: Friday, August 01, 2014 8:59 AM
> To: <public-hydra@w3.org>
> Cc: Markus Lanthaler
> Subject: Re: Proposed resolution for ISSUE-64 (status codes)
> 
> Dear all,
> 
> I personally strongly agree with Markus'
> > s/Remove all MUSTs about/Remove all normative statements about/
> and I find
> > There was no error, neither on the client nor the server side.
> 
> very convincing.
> 
> That said, I would like to move forward as follows.
> 
> The current specification for triple pattern fragments has:
> - Section 3. A large normative part on what triple pattern fragments look like;
> - Section 4. A small normative part on what HTTP servers of those fragments
> look like.
> 
> Given that the part on HTTP servers mostly consists of the status codes
> discussion (the remainder is variable expansion, which will move to the Core
> Vocabulary), this would allow us to reduce Section 4 to something very small
> and non-normative.
> 
> In other words, triple pattern fragments would be determined entirely by the
> documents, not any other interface agreements, which nicely agrees with
> the statement that "A REST API should spend almost all of its descriptive
> effort in defining the media type(s) used for representing resources and
> driving application state" [1].
> 
> Additionally, this would easily enable the deployment in non-HTTP
> environments, because the spec would essentially be protocol-independent
> (even though we would thoroughly explain how one can do it for HTTP).
> 
> This would then also be a great example of the power of hypermedia and a
> generic document type as enabled by the Hydra Core Vocabulary:
> no URLs, no protocol, just the document type.
> 
> Please let us know any comments, agreements, and/or disagreements.
> 

+1 (just for the record, I was strongly against the '404 just means empty' approach too, for all the reasons already stated.)

> Best,
> 
> Ruben
> 
> [1] http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

Received on Saturday, 2 August 2014 15:37:43 UTC