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

The most important reason for me is backwards compatibility. If I have had enough resources I could make a JSON-LD API right away, but for the sake of 'sellability' of API's (which happen to be very difficult at all in our business at least), I like the idea of 'upgrading' responses with JSON-LD in a later stadium, when people already use the data provided in the API and the investment has proven itself already.

Now I know that it's completely valid to just add a link to a context file in the response header not breaking backwards compatibility, but then you don't get the full benefits of JSON-LD in my opinion (like which actual @type a value is). Furthermore, when there is a triplestore in place already, converting triples back to JSON-LD doesn't really give me a developer friendly response.

For example, if I have

{
  "city": "London"
}

Just converting it to

{
  "@context": {
    "city": "http://schema.org/homeTown"
  },
  "city": "London"
}

Doesn't give me the full benefits because I still can't fetch more information about London. I'd like to see this instead:

{
  "@context": {
    "city": {"@id": "http://schema.org/homeTown", "@type": "@id"}
  },
  "city": {
    "label": "London",
    "@id": "http://dbpedia.org/resource/London",
    "@type": "http://schema.org/City"
  }
}

Which is a completely different response. Besides the design process takes more time (which links and vocabularies are we going to use) while we'd like to use rapid development to get the API 'out there' to convince people to use it.

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

Yes, I like this idea!

Received on Tuesday, 5 August 2014 15:57:07 UTC