Hi Bill
I'm not exactly sure which camp you have put me in here, or how is it
linked to my original query with all suddenly starting to agree to your
assumption :-). By the way, you may recall I've been opposed to any
explicit linking of JAX-RS to Servlet API.
Let me clarify. I'm considering and promoting JAX-RS as a spec that
makes complex things easy to do. Most of JAX-RS server side features is
not very straightforward to do manually.
HTTP-verb matching is the only feature, IMHO, that is not a complex
thing to do. It is a straight switch/comparison. I do not think it is
what makes JAX-RS superior to other alternatives.
I'm seeing a number of cases where people may want to use a JAX-RS
runtime but make an HTTP method based dispatch dynamic. In some other
cases, when people do say both POST and PUT on the same path, or GET and
OPTIONS and on the same path, it might be useful to have a mechanism to
have a single resource method matching such requests.
I like a @DefaultMethod idea. It can be used alongside @GET/etc, or it
can be used to have a JAX-WS like provider done if it is needed for a
given case. The fact that some other specification/API lets people do it
is not a good argument IMHO. I don't think it would weaken the API/spec
but make it more embracing...
At this point of time I'm not feeling particularly strong about
@DefaultMethod. I think it makes sense to have a Minor improvement
request for the spec leads to consider
Sergey
On 16/01/15 22:29, Bill Burke 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.
>
> 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
>>>
>>
>