users@jersey.java.net

RE: [Jersey] JAX-RS == REST? Or not? (was Re: [Jersey] What HATEOAS actually means)

From: Markus Karg <markus.karg_at_gmx.net>
Date: Thu, 18 Feb 2010 21:39:46 +0100

(generic client)

> OK, I think I understand now. But (you knew a "but" was coming - right)
> how do you think a generic client will find the links and know what to
> do with them. E.g. suppose a service uses media type
> application/widgets+json, how will the generic client identify the
> links in the representations and how will it know what HTTP methods are
> to be used without some additional configuration ?

About finding the links: As I agreed, the "Link" header is fine, and for
MIME types (but, again, not for particular frameworks like Jersey or
particular applications like "WebShop 3.5") there obviously will be a plugin
existing already on the client, since a client that asks for a PDF obviously
is able to understand PDF -- so the plugin could allow requests like
"plugin.findLinksForRole("leaveShop")".

About the http methods: Possibly by using OPTIONS on the URI to receive the
methods by Allowed:, but frankly this is an issue that I have not finally
solved. Possibly by pure RESTful definition: If I like to add something new,
it's a POST and so on (this is why not inventing things makes the world much
easier -- if we would all use GET, PUT, POST, DELETE, but not other things,
the choice would be clearer).

> As a standalone product how can it move beyond the initial steady state
> ? For browsers with human drivers this is easy, but for a headless
> generic client I don't see how it could work.

It's just as stateless as the server. ;-)

-start of cycle-. The workflow engine (Java application, batch script,
whatever) calls it, providing the URI and link role names to scan for
(obvisouly a workflow engine dealing with shopping processes would provide
e. g. a role name like "leave shop" at the end of a shopping tour for
example). The tool does the request, inspects the response, and gives back
the response and the found links to the caller. -end of cycle-. Then the
caller (workflow engine, Java application, batch script, whatever) can do
the next step by deciding which of the previously discovered links to follow
(just like man would surf the web), which is the start of a new cycle.