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.

Best,

Ruben

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

Received on Friday, 1 August 2014 08:00:04 UTC