Taking HATEOAS and REST to the extreme

[Filippos Vasilakis]

Hello! I was discussing with a friend about REST and HATEOAS and we agreed that REST+HATEOAS will work as long as the client knows how to parse the returned content. Given that the client first asks for specific content types using the accept header, client knows beforehand how to parse the server's answer.

Are there any thoughts to mitigate this beforehand knowledge? For instance the client could send a GET request requiring the server to first send a grammar describing the syntax of the response, essentially describing the whole standard that is going to be used.

[mca]

yep -- hypermedia clients need to know how to parse messages (HTML, Cj, Atom, Siren, etc.). that's key. but that is not at the *application* level, just the message level.  

FWIW, clients need to also know how to handle *protocols* like HTTP, XMPP, MQTT, etc.  and that's "lower" than the message level.

Finally, after sorting out protocol AND message semantics, the app either has to 

1) hand all this to a human

OR

2) make some decisions at the machine level (before/instead of dealing with humans)

and that is another level -- the *application-level* 

Most of the time developers conflate these three things (protocol, message, application) and find it hard to treat them separately. in fact, most tooling also conflates these and that doesn't help ;)

tooling that would allow service developers to design a service (using internal data/object models) and THEN press a button that allows the service provide to select one or more *protocols* to support (e.g. HTTP and XMPP) and then also support one or more *message models* (e.g. HTML, Siren, UBER) that would auto-magically map the app-level semantics against these messages would help a great deal. 

The only ppl i know of at the moment working around this kind of idea is the apiary.io team (Mark Foster, Stephen Mizell, Zdeněk Němec).

you might want also to check into Hydra and ALPS as they both are working on ways to apply application-level semantics (independently) to protocol-level messaging like JSON-LD (for Hydra) and a wide range of hypermedia types (for ALPS).

we're all used to accepting the "a priori" of protocol and message-level. HTTP makes messages a negotiable element, too. but we still balk at sorting out ways to make app-level semantics independent and negotiable. until we focus on that problem and get it solved in a reasonable way, developers will be stuck having to build bespoke, one-off apps for the foreseeable future.

mca

+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 Sun, Dec 7, 2014 at 6:19 PM, Filippos Vasilakis <vasila...@gmail.com> wrote:

Hello! I was discussing with a friend about REST and HATEOAS and we agreed that REST+HATEOAS will work as long as the client knows how to parse the returned content. Given that the client first asks for specific content types using the accept header, client knows beforehand how to parse the server's answer.

Are there any thoughts to mitigate this beforehand knowledge? For instance the client could send a GET request requiring the server to first send a grammar describing the syntax of the response, essentially describing the whole standard that is going to be used.

--
You received this message because you are subscribed to the Google Groups "API Craft" group.
To unsubscribe from this group and stop receiving emails from it, send an email to api-craft+...@googlegroups.com.
Visit this group at http://groups.google.com/group/api-craft.
For more options, visit https://groups.google.com/d/optout.