Oh and a little more additional info if you need it. I don't use this
functionality in a super hypermedia way. I just use it to have a self
describing API so my clients don't need hard coded REST paths.
So, for example, if the client GETs or POSTs a user they will get the JSON
representing the user but also a "rel" that contains the already expanded
path to their Account resource or their Preferences resource, etc. Already
expanded to mean that if they are user ID at 1 the Hateoas links would be
the fully qualified paths like /user/1/account and /user/1/preferences
respectively.
That's really all I use the HATEOAS stuff for.
On Mon, May 5, 2014 at 1:10 PM, Robert DiFalco <robert.difalco_at_gmail.com>wrote:
> I'm lacking some knowledge here.
>
> My REST API uses some HAL style HATEOAS responses. At a basic level the
> JSON entities I return have an "entity" field (for the actual entity) and a
> "links" field for a collection of links (usually containing at least one
> called "self" which is the link to the call just made to get the value of
> "entity".
>
> I notice JAX-RS has something different but that I could use instead of
> all the Hateoas stuff I rigged up.
>
> But here's where I'm confused. Is this a proprietary standard create by
> JAX-RS or does it map to some defined standard? Thinking of my clients, is
> there any reason I WOULD NOT want to use this instead of my home-grown
> solution that puts the links in the resource entity itself instead of how
> Jersey does it?
>
> Thanks for any facts or opinions you can offer on this!
>