On 12/16/2011 05:26 PM, Tatu Saloranta wrote:
> On Thu, Dec 15, 2011 at 10:18 PM, restkat <pansonm_at_yahoo.com> 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.
>>
> ...
>>
>> 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