[rest-practices] Media types

[Bryan Kearney]

On 04/15/2010 09:12 AM, Bill Burke wrote:
>
>
> Bryan Kearney wrote:
>> On 04/15/2010 08:53 AM, Eoghan Glynn wrote:
>>>
>>>
>>> > Is media type the preferred model for versioning rather than URL?
>>>
>>> Well I guess the answer might be influenced by the choice between a
>>> single over-arching media type and many fine-grained types. Because if
>>> the former, then specifying the version in the Content-Type would imply
>>> the versions of all fine-grained types are rev'd in lock-step. Which may
>>> potentially be awkward to maintain.
>>>
>>> > I could also see /v1/xxxx and /v2/xxxx as means of supporting
>>> incompatible versions.
>>>
>>> Might this approach lead to a higher likelihood of knowledge of the URI
>>> structure leaking out to the client side?
>>
>> It may. I think that this is my one concern around REST as it is
>> today. The client tools today make it easy to string up XML over HTTP
>> iff the clients know the url structure. The lack of an HATEoAS server
>> or client framework makes it much harder to gain adoption (today).
>>
>
> This is definitely a problem with RESTEasy's client proxy framework and
> leads me to believe that I should constrain it a little more and add
> deeper integration with media type processors like JAXB and Jackson if
> its possible (JAXB is pretty inflexible).

Not just client... server as well. The idea of a single object being 
used for Hiberante and REST is where I think most folks will start. 
However, there is a bit of a semantic break where REST would want Links 
and little to no relationships, where hibernate would want relationships 
and no links. I also wonder if a notion of url construction ala rails 
would be nice so I could reference customrUpdateLink(aCustomer).


-- bk