RE: Hypermedia and media types

Thanks for the replies!

Tomasz Pluskiewicz:

>Thus you don't need a media type for Hydra, because it is always 
>JSON-LD. That is unlike HAL and other non-LD approaches, which force a 
>completely different document structure.

Thing is that I want to be able to specify whether I want hypermedia (Hydra in the JSON-LD case) in my response or not. HAL, JSON-API and all the other non-LD Hypermedia standards out there allow me to do so using the Accept header because they have their own media types.

Markus Lanthaler:

>How would a client be able to "to paginate through collections of data" in
>that case?

In that case they probably don't want to paginate. I don't know my consumers. But I do know that as a consumer myself, I want the option to fetch a resource without hypermedia. For instance when I want to have the RDF version of the resource, using content-negotiation. I don't need hypermedia in there. And that's exactly my point: an API is just another way to present data. If you present information (LD), then I think hypermedia controls have nothing to do with the resource itself. An allowed HTTP method has nothing to do with a 'book' for example.

Thomas Hoppe:

>That's of course true and that's why you would not store them in your 
>persistence layer.
>We enrich the resources read from the database (there is no nee to 
>employ a triple store btw.)
>with the operations dynamically when they are delivered to solve this.

This is exactly what I mean! So if the consumer wants to fetch the 'real' data (which comes directly out of the persistence layer, ofcourse with some authorisation in mind, but you know what I mean) he/she should be able to request that.

Thomas Hoppe:

>Building APIs with hydra and JSON-LD for 3 years now and knowing those 
>others
>that are around [1] I can tell you that this is noble goal but if you 
>are in a typical
>project setting hardly possible because you will get killed by the effort.
>If you are talking about dumb transformation of serialization formats
>like JSON-LD to RDF/XML etc. then you are certainly right.
>But even supporting JSON-LD (+Hydra) and plain JSON is a whole different story.
>There is so much more you need to consider and implement in your API
>server for JSON-LD compared to JSON.
>Not to mention the challanges if you have to drive a "procedural model"
>(operations in the case of hydra). There is simply not 
>a 1:1 relation of concepts in hydra, HAL, siren, JSON API etc.

The reason I started this discussion is because we are working on a tool which automates this, making it easier for people to support multiple hypermedia types. However, I still think people should be able to 'disable' hypermedia in the response. Almost everyone returns application/hal+json when a consumer requests application/json. This breaks backwards compatibility if I ever want to return the plain JSON without hypermedia, so I think this assumption is wrong. If you support both application/json and application/hal+json, the consumer (which I don't know!) can choose to accept hypermedia or not. If you support application/ld+json the consumer appearantly can not make this choice, because the server decides if the application/ld+json response contains Hydra or not.


Markus Lanthaler:

>You could define a profile as Ruben already mentioned. An alternative might
>be to use the Prefer header [1] (either by using "return=minimal" or
>defining a new preference).

Interesting, I'm going to investigate the "return=hypermedia" option ;-)
________________________________
> To: public-hydra@w3.org 
> From: thomas.hoppe@n-fuse.de 
> Date: Wed, 19 Aug 2015 06:55:43 +0200 
> Subject: Re: Hypermedia and media types 
> 
> If you are talking about dumb transformation of serialization formats 
> like JSON-LD to RDF/XML etc. then you are certainly right. 
> But even supporting JSON-LD (+Hydra) and plain JSON is a whole 
> different story. 
> There is so much more you need to consider and implement in your API 
> server for JSON-LD compared to JSON. 
> Not to mention the challanges if you have to drive a "procedural model" 
> (operations in the case of hydra). There is simply not 
> a 1:1 relation of concepts in hydra, HAL, siren, JSON API etc. 
> 
> 
> On 08/18/2015 10:51 PM, mike amundsen wrote: 
> <snip> 
> if you are in a typical project setting hardly possible because you 
> will get killed by the effort. 
> </snip> 
> 
> you don't need to "kill yourself" adding support for message models. 
> 
> using a typical Strategy pattern[1] and a canonical resource object 
> model, I am able to add support for a new media type in <300 lines of 
> NodeJS. that means I can build up a new representor (discussion at [2]) 
> in a single day and debug/tweak it in another day or so. that's around 
> 20 work hours between selection and production. 
> 
> hope this helps. 
> 
> 
> [1] <http://www.oodesign.com/strategy-pattern.html> 
> http://www.oodesign.com/strategy-pattern.html 
> [2] <https://groups.google.com/forum/#%21msg/hypermedia-web/FXy1Mcuhj_0/W3aehrijwh0J> 
> https://groups.google.com/forum/#!msg/hypermedia-web/FXy1Mcuhj_0/W3aehrijwh0J<https://groups.google.com/forum/#%21msg/hypermedia-web/FXy1Mcuhj_0/W3aehrijwh0J> 
> 
> 
> mamund 
> +1.859.757.1449 
> skype: mca.amundsen 
> http://amundsen.com/blog/ 
> http://twitter.com/mamund 
> https://github.com/mamund 
> http://linkedin.com/in/mamund 
> 
> On Tue, Aug 18, 2015 at 4:21 PM, Thomas Hoppe 
> <thomas.hoppe@n-fuse.de<mailto:thomas.hoppe@n-fuse.de>> wrote: 
> Hi Dimitri, 
> 
> just my 50 cents on two aspects from your mail. 
> 
> "In my opinion, methods, operations and validations has got nothing to 
> do with the data itself" 
> 
> That's of course true and that's why you would not store them in your 
> persistence layer. 
> We enrich the resources read from the database (there is no nee to 
> employ a triple store btw.) 
> with the operations dynamically when they are delivered to solve this. 
> 
> "I'm about to start supporting them all and let the client choose which 
> one to use" 
> 
> Building APIs with hydra and JSON-LD for 3 years now and knowing those others 
> that are around [1] I can tell you that this is noble goal but if you 
> are in a typical 
> project setting hardly possible because you will get killed by the effort. 
> 
> Greets, Thomas 
> 
> [1] http://vanthome.github.io/rest-api-essay-presentation/rest_apis.html 
> 
> 
> On 08/18/2015 05:31 PM, Dimitri van Hees wrote: 
> Hi all, 
> 
> I'm designing an API and I am struggling with the choice of supported 
> hypermedia standards. Fact: we need to paginate through collections of 
> data. I'd like to offer both plain JSON and JSON-LD and let the client 
> choose which response he wants using the accept header. This is no 
> problem because we can simply use application/json and 
> application/ld+json. 
> 
> Problems arise when we also want to add hypermedia to the response. In 
> my opinion, one of the hypermedia versions of my the JSON response is 
> HAL, returned when application/hal+json is being requested. The 
> hypermedia version of the JSON-LD response should be Hydra, but as far 
> as I know Hydra doesn't have it's own media type because it's in fact 
> just valid application/ld+json. However, JSON-LD is also in fact just 
> valid application/json, yet still has it's own media type. Just like 
> HAL by the way, which is also just valid application/json. 
> 
> I think that one of the nicest things of JSON-LD is that it can be 
> converted to RDF and that the URL actually is the object itself. So I 
> want to give people the choice between fetching just the resource in 
> JSON-LD *and* fetching the resource with hypermedia (Hydra in this 
> case). In my opinion, methods, operations and validations has got 
> nothing to do with the data itself, so I can imagine use cases where I 
> don't want that data in a triplestore for example. As Hydra doesn't 
> have it's own media type, what would be the best practice to achieve 
> this? 
> 
> The same counts for the non LD responses by the way. There are so many 
> hypermedia standards out there that I can't choose which one to use. In 
> fact I think I'm about to start supporting them all and let the client 
> choose which one to use. But then again, there should also be a 
> possibility to fetch just the plain old JSON object, without any 
> hypermedia. Then again, most people always return hypermedia (say 
> application/hal+json), even when the accept header is application/json. 
> Perhaps there should be something like application/raw+json... ;-) 
> 
> Any thoughts on this? 
> 
> Regards, 
> 
> Dimitri van Hees 
> 

Received on Wednesday, 19 August 2015 06:45:32 UTC