Re: "Plain JSON" vs Hydra

Hi Dimitri,

> However, in my opinion, JSON-LD is just another response format.

Yes—but it has a benefit (over JSON) that it's properties have universal interpretation.
I.e., compare "name"/"Name" to "foaf:name".

> Now i know that JSON-LD is basically (completely valid) JSON, but still I'd like to provide both "Plain JSON" and JSON-LD responses.

Could you explain the reasoning behind this?
Ignoring stuff shouldn't be difficult for consumers, right? :-)

> That said, if someone sends the accept header application/json, I won't bother him/her with @types, external links and @context values. If someone sends the accept header application/ld+json, I return a JSON-LD document, with more than 'just' a link to a context file in the response header so that it actually makes a lot of sense to use this representation.

That seems fine, yes.

> When implementing Hydra, there is no alternative to 'explore' your API in the "normal" application/json response.

Why would that be necessary then?
People who want generic hypermedia controls, sign up for responses that allow for generic hypermedia controls.

> I could implement something like HAL for that response I guess, but then I'd have to do both.

You could still choose to strip off the information in the plain JSON version;
the interpretation will then simply be proprietary.

I.e., still use Hydra properties (structurally speaking), just not actually.
Or see it as an “implicit external context”.

> My guess is that the majority of the people on this list like to only provide a application/ld+json response instead of both.

Because technically, it is course already both.
It is already "Plain JSON", nothing can make it "plainer".
You can just remove JSON-LD-compatibility, sure. But what does that gain?

Best,

Ruben

Received on Tuesday, 5 August 2014 15:31:28 UTC