On Sep 1, 2009, at 9:09 AM, Felipe Gaúcho wrote:
> 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...)
>
I think for a HATEOS it makes a lot of sense, especially if the
framework can automate it as it separates the concerns of the database
from the hyper-media layer. Although i do wonder what would be the
alternative approaches if something other than a relational DB were
used.
> 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....
>
Storing absolute URLs or paths in the DB may not a good idea,
especially if data is reused within different contexts e.g.
GET /purchase-orders
GET /customers/1/purchase-orders
The first will get the representation of the set of all purchase
orders, the second the set associated with a customer, thus the URLs
in the former representation may be /purchase-orders/1 etc. where as
in the latter they may be /customers/1/purchase-orders/1 etc.
It may be possible in some circumstances to store relative paths that
are then turned into absolute paths.
> HATEOS is important.. if we can find a comfortable way of including it
> as default feature of our framework, we gain a good diferential.. :)
>
Indeed it is something we did not have time to tackle in JAX-RS 1.x
and would like to do so for any JAX-RS 2.0 effort.
Paul.
> 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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>