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.
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?
Tim Moores
Rancher
Joined: Sep 21, 2011
Posts: 2407
posted
0
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.
Why not?
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.
Then create another resource that DOES correspond to that setting.
Ivan Krizsan
Bartender
Joined: Oct 04, 2006
Posts: 2193
posted
0
Hi!
If you cannot think of an appropriate resource:
There is nothing wrong with using JAX-RS to implement a XML-over-HTTP (or JSON-over-HTTP) web service.
You already seem to understand that this would not be a RESTful web service, so avoid calling it a REST web service and you are good to go.
Best wishes!