ok, I will take some time on this topic.. but: my data comes directly
from the database, I usually avoid any post-processing on the data
after reading the DB .....
so, any trick that involves to iterate over a list including extra
info on the entities seems not good.. (at least right now...)
perhaps I can reinforce this during the entities creation, declaring a
field href on every entity and to do this URLs resolving during the
entity creation.. in this case, to include only the relative path of
the resource....
HATEOS is important.. if we can find a comfortable way of including it
as default feature of our framework, we gain a good diferential.. :)
let's see.. a fun investigation ahead...
On Tue, Sep 1, 2009 at 8:56 AM, Paul Sandoz<Paul.Sandoz_at_sun.com> wrote:
>
> On Sep 1, 2009, at 12:50 AM, Richard Wallace wrote:
>
>> 2009/8/31 Felipe Gaúcho <fgaucho_at_gmail.com>:
>>>
>>> so, I am thinking to include an href in each of my response elements..
>>> following the strict HATEOS principle..
>>>
>>> at least to have an hypertext reference on the root elements...
>>>
>>> How it is the most effective way of doing that ?
>>>
>>
>> Something that I've done in the past is create a Link class that is
>> JAXB annotated like
>>
>> public class Link {
>> @XmlAttribute private final String href;
>> @XmlAttribute private final String rel;
>> @XmlElement private final String value;
>>
>> // ctor, builders and getters omitted
>> }
>>
>> Then you can use it in other representations like
>>
>> @XmlRootElement
>> class MyRepresentation {
>> @XmlElement private final Link self;
>>
>> MyRepresentation(MyObject o, UriBuilder uriBuilder) {
>> self =
>> Link.href(uriBuilder.path(MyResource.class).build(o.getName())).rel("self");
>> }
>> }
>>
>
> Yes, and recall that you can use UriInfo to get the previously matched URIs
> of super resources as well.
>
> Brett proposed a different solution using JAXB and some AOP:
>
> http://markmail.org/search/?q=list%3Anet.java.dev.jersey.users+Dargan#query:list%3Anet.java.dev.jersey.users%20Dargan+page:1+mid:tw5grz5mamd2fey6+state:results
>
> There are likely to be other ways using JAXB serialization extensibility.
>
> This is an area we need to improve on, I have just not had the sustained to
> focus on this important area yet. In general it may be harder to provide a
> generic solution than a solution that is specific to JAXB.
>
> Paul.
>
>> But that's only applicable if you're using JAXB. If not, then I would
>> imagine you could use some similar strategy as long as you can get
>> access to the UriBuilder, know the values you want to substitute into
>> the path and you know the resource class you are building the path to.
>>
>>> other: should I include a full http URL like
>>> "http://resouce/path1/path2" or just the paths ? like "path1/path2" ?
>
> I recommend placing absolute URIs with host information, as this will make
> it easier for the client.
>
> Paul.
>
>>>
>>> --
>>> Looking for a client application for this service:
>>> http://fgaucho.dyndns.org:8080/footprint-service/wadl
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>
>
--
Looking for a client application for this service:
http://fgaucho.dyndns.org:8080/footprint-service/wadl