By the way, in that JIRA I also pointed out that JAX-RS has wildcards
for Consumes/Produces and Path. This can let people write the code with just
@Path("{var:.*}")
class MyResource {
@GET doIt();
}
and inside do it deal with all of the possible media types, and check
all the path segments... yet the JAX-RS developers probably do it in 5%
cases max. In this regard there's nothing special about a method wildcard
Sergey
On 22/01/15 15:18, Sergey Beryozkin wrote:
> On 22/01/15 14:12, Bill Burke wrote:
>> I think I might have been confused what @DefaultMethod was supposed to
>> be...You wanted @DefaultMethod on the ServiceProvider interface?
>>
> I did the specify best to clarify what my current thinking is. No
> ServiceProvider.
>>
>> 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.
> This is all the speculation.
>
>> There's just
>> no need to introduce something new.
>
> Unless someone else recommends 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
>>>
>>
>
>