users@jersey.java.net

Re: [Jersey] Putting the RESTful "connectedness" around my existing Domain objects

From: António Mota <amsmota_at_gmail.com>
Date: Mon, 27 Apr 2009 09:51:06 +0100

As I said, there's nothing wrong with that. However, doing that implies that
the application doesn't respect the HATEOAS constraint, even if it has
"connectedness". And if it doesn't respect that constraint it's not a
Restfull application. And doesen't possess the characteristics that that
constraint allows, meaning scability via decoupling from client and server.

But of course there's nothing wrong with not being Restfull, as long as
people are aware of that and what that means.

Neverthless, I realise that this is the Jersey list, not the Rest list, so
there is no point in discussing this in here.
_______________________________________________

Melhores cumprimentos / Beir beannacht / Best regards

António Manuel dos Santos Mota

_______________________________________________



2009/4/26 James Strachan <james.strachan_at_gmail.com>

> On 25/04/2009, António Mota <amsmota_at_gmail.com> wrote:
> > What a interesting thread I miss :)
> >
> > Although the "operational" effects of the solution described are
> effective,
> > and I don't doubt that a app build like that will work, I'll say however
> > that it is *not* a restfull solution.
> >
> > Basically, you are confusing the concept of "connectedness" with the
> concept
> > of "hipermedia as the engine of application state", or HATEOAS for short.
> >
> > Basically, hateoas doesen't mean that there should be "links" in the
> > resource representations, means more that the server should drive the
> > transitions between application states, and should do this in a way
> > independent of the client, without the client having out-of-band
> information
> > about it, namelly the "structure" of URI's.
> >
> > So, like Christmas, URI should be to any day a man wnats it to be. The
> > server should be capable of changing it's all structure of URI's without
> the
> > client knowing it. This is key for scabality.
>
> Though one of the powerful features of the web is linking - letting
> other services link to you, or letting your client use bookmarks.
> Changing URIs is usually bad - even if a 100% pure HATEOS client would
> not be affected - there are plenty of non-pure clients around, such as
> the browser I'm using to type this :-)
>
>
> >
> > On another point, Rest is about resources, not data, so comparing it to
> CRUD
> > is a dangerous and limiting thing to say...
> >
> > _______________________________________________
> >
> > Melhores cumprimentos / Beir beannacht / Best regards
> >
> > António Manuel dos Santos Mota
> >
> > _______________________________________________
> >
> >
> >
> >
> > 2009/1/29 James Strachan <james.strachan_at_gmail.com>
> >
> >> 2009/1/29 Paul Sandoz <Paul.Sandoz_at_sun.com>:
> >> > On Jan 28, 2009, at 3:37 PM, jstrachan wrote:
> >> >
> >> >> Or to say that another way - a URI is for life not for christmas;
> >> >
> >> >
> >> > Ho ho ho, nice quote :-)
> >>
> >> :)
> >>
> >>
> >> > I should stress that storing absolute URIs is a bad idea. Store
> relative
> >> > URIs (be they keys or not) which are then resolved to absolute URIs
> that
> >> > with the host, port, base path and may be a contextual path.
> >>
> >> Yeah; in my previous ramble I was only really considering relative
> >> URIs which a view layer might morph into an absolute URI with
> >> host/port/base path etc.
> >>
> >>
> >> > I also point you to Bret's further work in this area:
> >> >
> >> >
> >>
> http://markmail.org/search/?q=list%3Anet.java.dev.jersey.users+brett.dargan%40gmail.com#query:list%3Anet.java.dev.jersey.users%20brett.dargan%40gmail.com+page:1+mid:xjrp52mn7ywl4pdq+state:results
> >> >
> >> > Bret, sorry i have not had time to look at this in detail, but i
> really
> >> like
> >> > your solution.
> >>
> >> Yeah, it looks interesting.
> >>
> >> --
> >> James
> >> -------
> >> http://macstrac.blogspot.com/
> >>
> >> Open Source Integration
> >> http://fusesource.com/
> >> - Show quoted text -
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> >> For additional commands, e-mail: users-help_at_jersey.dev.java.net
> >>
> >>
> >
>
>
> --
> James
> -------
> http://macstrac.blogspot.com/
>
> Open Source Integration
> http://fusesource.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>
>