[jax-rs-spec users] Re: JAX-WS like Provider in JAX-RS

From: Marcos Luna <marcos.luna_at_email.com>
Date: Wed, 21 Jan 2015 15:14:30 +0100

Actually the http methods are 7 acording with the http 1.1 specification, the default method should react to all of them? or a specific default method for each one is a better idea? Something like

interface ServiceProvider {
Response invokePOST(InputStream is);
Response invokeDELETE(InputStream is);
Response invokeGET(InputStream is);
...
}

Just an idea.

If non annotated rest API will be available to manage non anotated operations, I think it should be very specific on the behavior of the available methods. So if you accept DELETE actions, you can separate those calls from the most common GET actions and do your updates and respond accordingly to each of your REST services if no method is defined to handle it.

Leaving a single default method can lead to bad habits like manage all your different request methods from a single point and you end with a mess of conditions.

--
Marcos

--------------
Marcos Luna Yela

Sent: Tuesday, January 20, 2015 at 12:47 PM
From: "Santiago Pericas-Geertsen" <Santiago.PericasGeertsen@oracle.com>
To: jsr370-experts@jax-rs-spec.java.net
Subject: Re: JAX-WS like Provider in JAX-RS

> On Jan 16, 2015, at 5:29 PM, Bill Burke <bburke@redhat.com> wrote:
>
> IMO, many of us continue to think of JAX-RS as Servlet.nextgen rather than a REST framework. Spec leads should really decide the direction here.

Personally, I don’t see these two views as mutually exclusive for JAX-RS. Especially when there often isn’t universal agreement on certain APIs being truly RESTful or not. Ultimately, it comes down to solving real-world problems, and in that context, I can see the benefit of @DefaultMethod.

— Santiago

>
> On 1/16/2015 5:11 PM, Sergey Beryozkin wrote:
>> Ha-Ha :-)
>>
>> The difference is JAX-RS has a richer context support. The JAX-RS
>> filters would still be there.
>> Something like @DefaultMethod, as Markus suggested, or something
>> similar, can work in principle.
>> I guess it is a weak case so far, I'll see how it goes in my current
>> project, perhaps some more ideas may arise...
>>
>> Sergey
>> On 16/01/15 19:30, Bill Burke wrote:
>>> Isn't there some specification in Java EE that allows you to do this for
>>> HTTP? I'm pretty sure Java EE has a non-annotated api for Java EE.
>>> Anybody know what it is? ;)
>>>
>>> On 1/16/2015 11:10 AM, Sergey Beryozkin wrote:
>>>> Hi All,
>>>>
>>>> Happy New Year,
>>>>
>>>> I've seen a number of times users asking how to have a dynamic JAX-RS
>>>> service which would support various HTTP methods but without having to
>>>> annotate. Something like JAX-WS Provider [1].
>>>>
>>>> How about introducing javax.ws.rs.ServiceProvider interface:
>>>>
>>>> interface ServiceProvider {
>>>> Response invoke(InputStream is);
>>>> }
>>>>
>>>> The implementation can inject a JAX-RS Request context and get an HTTP
>>>> verb name. UriInfo context will provide all the info about the request
>>>> URI including path and query parameters, HttpHeaders - about headers.
>>>> The injected Providers interface will help to read the stream into some
>>>> concrete object for Post/Put requests if needed.
>>>>
>>>> If a given object implements ServiceProvider then the JAX-RS
>>>> implementation will accept it as a service bean. @Path is defaulted to
>>>> "" if no @Path is available.
>>>>
>>>> I think it can be introduced into a spec (API, text) fairly easy but I'm
>>>> not expecting this proposal accepted easily too.
>>>>
>>>> Any comments ?
>>>>
>>>> Sergey
>>>>
>>>>
>>>>
>>>> [1] http://docs.oracle.com/javase/7/docs/api/javax/xml/ws/Provider.html
>>>
>>
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com