Sergey, Thanks for the idea...that sounds exactly like the kind of "back door" I need to get this done. Will study that today.
Regarding the hypermedia links themselves, there are a number of proposals out there for a standardized way to add link relations to REST payloads. Some folks advocate using HTTP Link headers. While this solution offers the added benefit of allowing an HTTP HEAD call to return just the links, it is incomplete as embedded subresources must have their own links. There is a REST framework called Restfulie (http://restfulie.caelum.com.br/) that I have looked at only briefly. It has a way to embed the links, though I don't think it is very transparent and doesn't use annotations for it (I've spent a grand total of 15 minutes studying it). Another standard I have looked at is called HAL (http://stateless.co/hal_specification.html). It is an interesting proposal, but I believe any standard for representing links should not BE the media type, but rather affect the media type in some standard way. Yet others advocate using the XML link element from the ATOM syndication format. I probably fall more into this camp, however I don't see the advantage (someone enlighten me please) to literally re-using the XML namespace and schema of Atom. I propose to embed atom-like link objects into the XML elements not as attributes, nor as sibling to the entity either, but rather as child elements. Something that could look like this: -------------------------------------------- <foo id="123"> <name>myFoo</name> <description>Another kind of foo altogether.</description> <links> <link rel="self" href="http://myserver.com/foos/123"; method="get" type="application/mything+xml"> <link rel="previous" href="http://myserver.com/foos/122"; type="application/mything+xml"> <link rel="next" href="http://myserver.com/foos/124"; type="application/mything+xml"> <link rel="edit" href="http://myserver.com/foos/123"; type="application/html-form+xml"> <link rel="cancel" href="http://myserver.com/foos/123?op="cancel""; method="post" type="application/mything+xml"> </links> </foo> -------------------------------------------- Part of the reason for the element wrapper "<links>" is to that the payload could be marshalled to JSON cleanly as well. I have not decided on the all the attributes of the "Link" class, but here is what I am thinking: For sure: rel - link relation URI. I am planning on reusing IANA ones where it makes sense and inventing them for my application as needed href - hypermedia reference. URL to dereference. Not sure if it should be absolute or relative yet. Maybe it could be both. I think it will need to be a URI template sometimes. method - HTTP method to use title - Optional human readable short name for this link Maybe?: description - Optional longer (e.g. 1 sentence) human readable explanation of the link types - Optional list of available media types for the response. Could cut down on unnecessary con-neg if used by clients Because these hypermedia links are only used in REST (e.g. not SOAP) I would want the links to be inserted as part of the marshaling process when in a REST context. It's important that the XML payloads for SOAP not be cluttered up with this noise. Yet, the structure of the links needs to be included in any generated XML schema file else schema validation will fail. I have no idea how to handle that. Again, there is no unmarshaling required. Which hypermedia links are available for any given object is a function of that object's state at the time of marshaling. Thus I do not think this can be handled by static annotations, because you need to compute the applicability of each link relation based on (potentially internal) properties. With no other idea on the table, I was planning on using the visitor pattern to accomplish this. That is, I would create a function object that, when given the object to be marshaled, would compute the hypermedia link objects and "do something" with them. Presumably, the function object would use the URL builder APIs. -- View this message in context: http://cxf.547215.n5.nabble.com/Good-way-to-add-link-relations-to-REST-responses-tp5461580p5463281.html Sent from the cxf-user mailing list archive at Nabble.com.
