users@jersey.java.net

RE: [Jersey] What HATEOAS actually means

From: Markus Karg <markus.karg_at_gmx.net>
Date: Mon, 15 Feb 2010 22:13:34 +0100

Maybe it is time to show a "real" HATEOAS workflow:

You have an order, and want it to get shipped by UPS as soon as VISA
confirms payment.

The client has the order XML. It is in the state of "neither paid nor
shipped". So it contains one link (Payment).

The client understands this status as it knows the word "pay" (found in the
link's role description), so what it does is invoke the payment process via
this URI. It uploads the unpaid order and gets back a paid order. So state
now is "paid but not shipped". So it contains a different link (Ship).

The client understands this status as it knows the word "ship" (found in the
link's role description), so what it does is invoke the shipping process via
this URI. It uploads the paid order and gets back a shipping note (possibly
referencing the order by a URI, with a link role of "view"). So state is now
"shipped".

The client's guy presents the user a message that the order was paid and
shipped and asks whether the user will "view" it again. If he clicks on
"yes" then it will get downloaded again via the "view" URI. If he clicks
"no" the workflow is finished and the client discards state.

Just like a browser works. Just like Fielding wants it to work like.

No need for an API.

BUT: Possibly a declarative API as Marc proposed it would make *some*
people's life's easier (not mine: As I said, a hypermedia API is useless).

> -----Original Message-----
> From: Jan Algermissen [mailto:algermissen1971_at_mac.com]
> Sent: Montag, 15. Februar 2010 21:01
> To: users_at_jersey.dev.java.net
> Subject: Re: [Jersey] What HATEOAS actually means
>
>
> On Feb 15, 2010, at 8:48 PM, Jan Algermissen wrote:
>
> > As for entities - I don't see how you could go by without a plugin
> mechanism of some sort (like you need message body readers/writers).
> >
> > I am not sure a generic approach is feasible because hypermedia can
> take many forms
> >
> > - links
> > - link templates
> > - forms
> > - exotic (as in http://www.nordsc.com/blog/?p=293#cbcID-tweak )
> >
> > Basically a media type could define any kind of syntax for expressing
> a hypermedia link
>
> Thinking about all that I wonder with how many links a machine client
> would have to deal anyway. There is not much value in designing media
> types in a way that causes clients to have to execute sequences of
> requests to reach some goal.
>
> Placing an order would be something like
>
> - find the service
> - get the service document
> - find a resurce that accepts order submissions (a lookup in
> an AtomPub service doc using category and/or accept elements)
> - POSTthe order document
>
>
> Initiating shipment
>
> - find the service
> - get the service document
> - find a resource that accepts shipment requests (se above)
> - POST the shipemnt request.
>
> Polling for updates using Atom feeds
>
> - find the service
> - find the feed you are looing for (based on category)
> - GET the feed
> - follow next links until all new events have been seen
>
> I wonder if the amount of links that are involved in these scenarios
> warrant some sort of framework support.
>
> But yes, it is worth ivestigating.
>
> Jan
>
>
>
>
> >
> > Jan
> >
> >
> >
> >>
> >> -- Santiago
> >>
> >>
> >>
> >> --------------------------------------------------------------------
> -
> >> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> >> For additional commands, e-mail: users-help_at_jersey.dev.java.net
> >>
> >
> > -----------------------------------
> > Jan Algermissen, Consultant
> > NORD Software Consulting
> >
> > Mail: algermissen_at_acm.org
> > Blog: http://www.nordsc.com/blog/
> > Work: http://www.nordsc.com/
> > -----------------------------------
> >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> > For additional commands, e-mail: users-help_at_jersey.dev.java.net
> >
>
> -----------------------------------
> Jan Algermissen, Consultant
> NORD Software Consulting
>
> Mail: algermissen_at_acm.org
> Blog: http://www.nordsc.com/blog/
> Work: http://www.nordsc.com/
> -----------------------------------
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net