Re: Hypermedia and media types

<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
[2]
https://groups.google.com/forum/#!msg/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>
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
>>
>
>
>