users@jax-rs-spec.java.net

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

From: Bill Burke <bburke_at_redhat.com>
Date: Thu, 22 Jan 2015 09:12:14 -0500

I think I might have been confused what @DefaultMethod was supposed to
be...You wanted @DefaultMethod on the ServiceProvider interface?


Can you elaborate on how ServiceProvider would be registered/deployed?
Again, IMO, if backtracking were added to the matching algorithm, I
don't think we need a ServiceProvider interface. Users would just write
really generic Resource and Subresource locator classes. There's just
no need to introduce something new.

On 1/21/2015 4:58 PM, Sergey Beryozkin wrote:
> Hi
>
> That would be too explicit but also limiting (as Markus suggested) and I
> can not imagine the group accepting it, though one never knows :-).
>
> I agree it would offer an option for people to write all in a single
> method but to be honest I do not expect JAX-RS users at large starting
> doing it. It would just offer a very specific option in cases where
> people do really need it
>
> Sergey
> On 21/01/15 14:14, Marcos Luna wrote:
>> 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_at_oracle.com>
>> *To:* jsr370-experts_at_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_at_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
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com