users@jax-rs-spec.java.net

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

From: Markus KARG <markus_at_headcrashing.eu>
Date: Wed, 21 Jan 2015 18:19:50 +0100

I think there is a difference actually. Even with fixed backtracking, @DefaultMethod's semantics is to be a unique "catch any problem" disclaimer -- it catches even in case there are typos in the pattern, hence it can serve as a safety net in case "/{wildcard:.*}" is missing or wrongly typed, or in case there are two or more different patterns effectively matching on the same path but would route to different methods otherwise. Hence I see it as an additional option to fixing the algorithm.

Regards
-Markus

-----Original Message-----
From: Bill Burke [mailto:bburke_at_redhat.com]
Sent: Mittwoch, 21. Januar 2015 15:56
To: jsr370-experts_at_jax-rs-spec.java.net
Subject: Re: JAX-WS like Provider in JAX-RS

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