BTW, you wouldn't need @DefaultMethod if the matching algorithm wasn't
broken....For example, a sane matching algorithm would allow this:
@Path("/{wildcard:.*}")
public class DefaultOptionsBehavior {
@OPTIONS
public Response handleOption() {
}
}
But, unfortunately, as I've complained about over and over again, the
matching algorithm doesn't support backtracking after failing to resolve
the call with a more specific resource class. The TCK enforces this
broken behavior too...SO...we're stuck with discussing @DefaultMethod.
On 1/21/2015 9:14 AM, 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