Hi Sergey -- no brilliant ideas yet...just more thoughts:
Sergey Beryozkin-5 wrote > > FYI, this is what is proposed to be supported in JAX-RS 2.0: > http://java.net/projects/jax-rs-spec/pages/HypermediaExample > > Currently it's about the Link headers, I see the current proposal being > very good in simplifying the way such headers can be created or > extracted. There's an opinion that it's a bit early to standardize on > the other related options given the community is continuing with > experimenting in this area, which I agree makes sense for now. > > Thanks for the link. I agree it's a good proposal for link headers. However, I believe that link headers are insufficient for applications such as mine where we have machine clients reading complex object graphs with multiple levels of subresource embedding used to reduce the number of round trips. I get that HTTP has caching and all, but I can't see making 5-25 round trips to pull over an object and its primary child collections, to say nothing of the children themselves! But of course they must have already thought of that, because I also see in the proposal some discussion of links embedded in the representations themselves. They have a link class that has the same semantics as mine. Their attributes are "rel", "href", "method", and "produces". This is a good starting point for me. I won't plan on adding any more link attributes unless it becomes necessary. Sergey Beryozkin-5 wrote > > what I'm a bit pessimistic about, is the fact that the link elements (or > attributes) will become part of the actual foo's content where 'foo' is > a specific domain object. This is XML, not (X)HTML, presumably to be > consumed by a client code. Will that code cope with the possible > validation against the schema with the foo element having say a closed > content model ? > I would expect the client code to have enough shared understanding with the server to unmarshal the XML/JSON and understand what part is the "foo" and what part is the hypermedia links associated with the "foo". In this regard whether the links are in HTTP headers, siblings to Foo, or children of Foo doesn't matter...just so long as they are there somewhere. Life is easy when there are no standards!! I think the issue of schema validation of the server-marshaled XML (whether it be done on the server or client) is a real problem here. In order to generate a proper XML schema we are going to have to include the "links" element and the "link" type in the XML schema. Given the state of things today, there is no transparent way to do this. We must include those items in our JAX-B mapping, yes? Sergey Beryozkin-5 wrote > > The other thing which I referred to in the previous email, is this. It's > kind of next to impossible to guess the values such as 124 & 123 in your > example above at the level of the annotation, some basic 'guesses' can > be done say, assuming the value of the current @PathParam is 121 then > the prev link must be ending with 120, the next with 122. etc, but it's > not going to work as a general solution. > > Ideally, one would indeed have a bean property such as 'String href' or > List, etc, but as you said you have an existing rich model and neither > updating it all nor adding an adapter per every domain object is > practical, so it's quite compelling to get the right runtime support for > it. > Totally agree about how important it is to come up with the correct runtime support. To that end, here are some thoughts: The creation of the collection of links for an entity requires knowledge of four things: 1) Which link relations are possible for this type of entity - either the resource or the entity can know this 2) Which of the possible link relations are application given the current state of the entity - this requires access to the state of the entity 3) What should the URL be for the link - this requires information akin to a URI template that needs to be filled in with information from the object graph (the entity ID, its parent's ID, etc). 4) Knowledge of the media type being returned to the client. One resource can (and often does) support multiple media types, and each media type is going to come with different link relations. In other words, the code required to generate the links cannot simply be added to the domain model because it doesn't know about media types and it can't make a URL. Likewise it can't be done like the "getTransitionalLinks" method in the JAX-RS 2.0 example you pointed me to because it requires access to the entity and to the media type being marshaled and it doesn't traverse the generated object graph. Sergey Beryozkin-5 wrote > > IMHO the answer is in determining who the actual consumer is. > > If this payload were to be processed and converted into HTML then may be > a better option return a container bean which RequestDispatcherProvider > will make available to JSP or similar, example: > > @GET > public ContainerBean get(@Context UriInfo ui) { > > ContainerBean bean = new ContainerBean(); > Foo foo = new Foo(); > bean.setDomainObject(foo); > List<Link> links = calculateAbsoluteLinks(foo, ui); > bean.setLinks(links); > return bean; > } > > The JSP/etc will show the contents of Foo and will nicely add links for > a user to explore... > In my case, the client is a Javascript program that acts takes the payload+links in XML/JSON and does something useful with it. It's not at all the case that these XML links will be directly clicked on by a user, more likely they're existence will be used to enable/disable command bar buttons that when clicked will result in another HTTP call. -- View this message in context: http://cxf.547215.n5.nabble.com/Good-way-to-add-link-relations-to-REST-responses-tp5461580p5464718.html Sent from the cxf-user mailing list archive at Nabble.com.
