Re: Don't specific media types introduce coupling?

Hi Ruben,

On Oct 18, 2012, at 12:49 PM, Ruben Verborgh wrote:

> Hi all,
> 
> It’s an often-discussed topic that continues to puzzle me:
> self-descriptiveness is encouraged to reduce coupling,

No. Self descriptiveness is there to allow intermediaries to do something with the request (e.g. caching, retry until response retrieved for idempotent methods) as opposed to merely passing it on (they are not at the transport level but at the transfer level (application level)).

> but how specific can we describe without introducing coupling?

Contracts do exist in REST, the difference to RPC is that they are centrally owned (as opposed to server owned). Both, client and server couple to these central contracts but not to *each other*.

> And specifically: to what extent could “self-describing” formats such as RDF help out here?

RDF-aware clients are just that - RDF aware. There is no magic in REST that suddenly allows clients to come up with implementation logic that has not been baked into them when they where coded. REST doesn't make the problems of decentralized systems (where communication between client owner and server owner is impossible or too costly) go away.

Quite the opposite: REST makes them explicit (e.g. SOA(P) hides them while implying to solve them), forces you to deal with them but also provides you with a 'conceptual framework' to deal with them in a controlled way. (Well, actually REST allows you to design an architecture that allows you to deal with them in a controlled way. HTTP is such an architecture).

HTML and AtomPub are good example of such centrally owned contracts. While they seem rather generic, there is actually a lot of stuff that is highly specific (take client side image maps in HTML for example). Clients that implement support for them couple themselves to the contratc the specs describe.

Now, HTML and AtomPub are designed to realize use cases that turn to a human user often for making descisions in what action step to take next.

If you want to realize use cases where the human actor is much less involved (and the user agent does a lot more on its own) you need to come up with media types (and/or link relations) that provide the necessary hypermedia semantics to write such user agents.

If you do not do that (write specific media types) but instead use generic ones (application/xml, application/json) you absolutely, 100%, need some out of band coupling somewhere if you want your client to do more than 'parse as xml' or 'parse as json'. And you will, immediately, end up with a non RESTful architecture where out of band contract is owned and changed by the server.

This need not be bad, but it is likely to produce the same probles in the long run that to avoid made you look at REST in the first place.

Either way, understand the tradeoffs of what you are designing - this is probably the most valuable lesson that Roy has tought us (me anyway) with his work.

As for some discussion of the tradeoffs you might find[1] interesting.

HTH

Jan

[1] http://www.nordsc.com/ext/classification_of_http_based_apis.html




> 
> Let me borrow the Maze+XML example used in a previous discussion [1].
> So the problem is: a server exposes a maze, a client needs to be able to navigate through it.
> Basically, there are two options:
> 1) Use a generic format (such as JSON) and explain separately what the different fields mean.
> 2) Use a specific format (such as Maze+XML); no need to explain, everything is in the media type.
> 
> At first, it seems like the second solution minimizes the amount of out-of-band information, as solution 1 involves a separate explanation document (which might or might not be expressed in a machine-processable way). But if you think about it, solution 2 has the exact same amount of out-of-band information, only this time it has moved to the interpretation of the media type’s specification. In both cases, the client needs to be adapted specifically to interact with the media type. And how decoupled is it when client and server are constrained to a specific message format?
> 
> Things _could_ be different with a self-describing format, as this might overcome the need for specific media types. So here’s another situation:
> 3) Use a self-describing format (such as RDF); no need to explain, and the client can work this out by itself.
> (Although I’m being slightly overoptimistic about RDF now.) The idea would be that the client can interpret the representation as being a maze, and continue to use it that way.
> 
> My basic question is thus: do specific media types really reduce coupling, and if not, what does?
> 
> Best,
> 
> Ruben
> 
> [1] https://groups.google.com/d/topic/hypermedia-web/LdKfi47QCxw/discussion
> 
> 
> 
> 
> ------------------------------------
> 
> Yahoo! Groups Links
> 
> 
> 



------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/rest-discuss/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/rest-discuss/join
    (Yahoo! ID required)

<*> To change settings via email:
    [email protected] 
    [email protected]

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/