JAX-RS RESTful Interface for actions ???

[restkat]

I’ve been using JAX-RS and like the simplicity and marshaling of parameters
and responses.

I'm reading about how to design the URI space and also like the simple,
resource centric approach.

But when it comes to performing actions from an HTTP client that do not
pertain to CRUD operations against a resource, am I supposed to use a
different technology? That doesn't make any sense. Now I have JAX-RS for the
resource centric requests and maybe POX over HTTP for invoking actions. Two
different frameworks to maintain...this would be an abomination from a
maintenance and testing perspective.

Here's an example I'm working with related to a simple TV Guide client:

For getting and displaying a TV guide, REST fits well. You can imagine URI's
like /programs and /programs/{programId}.

But once I have a program object and want to tell the back end to tune my TV
to the appropriate channel to watch the program, REST doesn't make much
sense. I'm telling the back end to tune a set-top box to channel 4. That
doesn't have much to do with the original resource. The closest URI I can
come up with is something like

PUT /set-top/{id}

But that doesn’t sound right.

Certainly you could use JAX-RS to expose the interface, but it wouldn't be
REST and everything I read says that this is wrong.

Ideas?

--
View this message in context: http://jersey.576304.n2.nabble.com/JAX-RS-RESTful-Interface-for-actions-tp7099767p7099767.html
Sent from the Jersey mailing list archive at Nabble.com.

[algermissen1971]

On 16 Dec, 2011,at 07:18 AM, restkat <pansonm-/***@public.gmane.org> wrote:

I’ve been using JAX-RS and like the simplicity and marshaling of parameters
and responses.

I'm reading about how to design the URI space and also like the simple,
resource centric approach.

But when it comes to performing actions from an HTTP client that do not
pertain to CRUD operations against a resource, am I supposed to use a
different technology? That doesn't make any sense. Now I have JAX-RS for the
resource centric requests and maybe POX over HTTP for invoking actions. Two
different frameworks to maintain...this would be an abomination from a
maintenance and testing perspective.

Here's an example I'm working with related to a simple TV Guide client:

For getting and displaying a TV guide, REST fits well. You can imagine URI's
like /programs and /programs/{programId}.

But once I have a program object and want to tell the back end to tune my TV
to the appropriate channel to watch the program, REST doesn't make much
sense. I'm telling the back end to tune a set-top box to channel 4.
 
What you describe is the intent to change the tuner settings state to have an active channel of 4. Consider:

PUT /set-top/settings
Content-Type: application/vnd.foo.tuner-settings

<tunerSettings>
  <volume>6</volume>
  <channel group="analog">4</channel>
  <!-- more settings because PUT is not a partial update-->
</tunerSettings>

or sth like

PATCH /set-top/settings
Content-Type: application/vnd.foo.tuner-settings-diff

<tunerSettingsChange>
  <channel group="analog">4</channel>
</tunerSettingsChange>

if you like to go for partial updates.

Beware that there is quite a lot to learn about REST because it involves *a lot* more aspects than POX over HTTP and I suggest you take questions to the rest-discuss mailing list[1] or to SO[2]. The REST folks there will be happy to answer.

Jan

[1] http://tech.groups.yahoo.com/group/rest-discuss/
[2] http://stackoverflow.com/questions/tagged/rest




That
doesn't have much to do with the original resource. The closest URI I can
come up with is something like

PUT /set-top/{id}

But that doesn’t sound right.

Certainly you could use JAX-RS to expose the interface, but it wouldn't be
REST and everything I read says that this is wrong.

Ideas?

--
View this message in context: http://jersey.576304.n2.nabble.com/JAX-RS-RESTful-Interface-for-actions-tp7099767p7099767.html
Sent from the Jersey mailing list archive at Nabble.com.

[Tatu Saloranta]

Post by restkat
I’ve been using JAX-RS and like the simplicity and marshaling of parameters
and responses.
I'm reading about how to design the URI space and also like the simple,
resource centric approach.
But when it comes to performing actions from an HTTP client that do not
pertain to CRUD operations against a resource, am I supposed to use a
different technology? That doesn't make any sense. Now I have JAX-RS for the
resource centric requests and maybe POX over HTTP for invoking actions. Two
different frameworks to maintain...this would be an abomination from a
maintenance and testing perspective.

...

Post by restkat
Certainly you could use JAX-RS to expose the interface, but it wouldn't be
REST and everything I read says that this is wrong.

In my opinion, there is nothing wrong in using JAX-RS implementation
like Jersey purely for binding URLs and other HTTP pieces with code to
invoke, and to simplify binding, content negotiation.

Question, rather, is whether REST model is the way to go or not; and
after that higher-level decision, which tool(s) to choose.
I can see Jersey working just fine RPC style access, or REST-like combinations.

Put another way: while many may argue that REST is better way to go
for any given use case, fewer (if any) would object to using
general-purpose framework. Even if that "R" in there did come from
term REST. :-)

-+ Tatu +-

[Marek Potociar]

Post by Tatu Saloranta

Post by restkat
I’ve been using JAX-RS and like the simplicity and marshaling of parameters
and responses.
I'm reading about how to design the URI space and also like the simple,
resource centric approach.
But when it comes to performing actions from an HTTP client that do not
pertain to CRUD operations against a resource, am I supposed to use a
different technology? That doesn't make any sense. Now I have JAX-RS for the
resource centric requests and maybe POX over HTTP for invoking actions. Two
different frameworks to maintain...this would be an abomination from a
maintenance and testing perspective.

...

Post by restkat
Certainly you could use JAX-RS to expose the interface, but it wouldn't be
REST and everything I read says that this is wrong.

In my opinion, there is nothing wrong in using JAX-RS implementation
like Jersey purely for binding URLs and other HTTP pieces with code to
invoke, and to simplify binding, content negotiation.
Question, rather, is whether REST model is the way to go or not; and
after that higher-level decision, which tool(s) to choose.
I can see Jersey working just fine RPC style access, or REST-like combinations.
Put another way: while many may argue that REST is better way to go
for any given use case, fewer (if any) would object to using
general-purpose framework. Even if that "R" in there did come from
term REST. :-)
-+ Tatu +-

It's certainly true that JAX-RS impls can be used in non-restful ways and I agree that it's vital to support additional
use cases outside the box of pure REST architectures.

That said, the JAX-RS as an API remains focused primarily on making it easy to develop RESTful solutions. IOW the "R"
really does come from "REST". ;) FWIW, personally I'm not convinced about 'X' which seems somewhat tendentiously chosen...

In any case, in the context of the original question, I can +1 on Jan's answer.

Marek