Hi Santiago
I'll open a Minor JIRA issue shortly
Sergey
On 21/01/15 20:34, Santiago Pericas-Geertsen wrote:
> All,
>
> Seems to me that Markus and Sergey are thinking along the same lines
> as to what could be done here. Would it be possible for the two of you
> to sync up and provide a single proposal?
>
> It should be easy to integrate into the existing algorithm and,
> hopefully, possible to describe in a couple of sentences.
>
> — Santiago
>
>> On Jan 21, 2015, at 12:40 PM, Markus KARG <markus_at_headcrashing.eu
>> <mailto:markus_at_headcrashing.eu>> wrote:
>>
>> First of all, it is impossible to use named path parameters if you do
>> not have an annotation. Using @DefaultMethod("{path}") it is. Hence,
>> not using annotations reduces the number of useable features.
>> Second, RFC 2616 chapter 9's introduction clearly says that the set of
>> methods is infinite, not statically 7. Hence the annotations are
>> needed to defined the routing from http method to Java method. In some
>> cases, it makes sense to share a common implementation, or to catch
>> unclear routing information. This is what @DefaultMethod would allow
>> to do. It is implicitly impossible to route multiple http methods to
>> the same fallback method in your proposal. What you propose is not
>> "default routing" to catch-all (which is the idea behind
>> @DefaultMethod) but you propose "default names" to get rid of
>> annotations (which is not a target of JAX-RS revisions AFAIK). Your
>> proposal is more or less already covered behind my proposal of
>> december 2009 (https://java.net/jira/browse/JAX_RS_SPEC-18) already.
>> Did you check that before?
>> *From:*Marcos Luna [mailto:marcos.luna_at_email.com]
>> *Sent:*Mittwoch, 21. Januar 2015 15:15
>> *To:*jsr370-experts_at_jax-rs-spec.java.net
>> <mailto:jsr370-experts_at_jax-rs-spec.java.net>
>> *Subject:*Re: JAX-WS like Provider in JAX-RS
>> 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
>> <mailto:Santiago.PericasGeertsen_at_oracle.com>>
>> *To:* jsr370-experts_at_jax-rs-spec.java.net
>> <mailto: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 <mailto: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 <http://bill.burkecentral.com/>
>