cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sergey Beryozkin" <sbery...@progress.com>
Subject Multiple HTTP methods per method in JAXRS (Re: Possibly retarded question)
Date Thu, 12 Mar 2009 15:24:24 GMT
I renamed the subject a bit :-)

I don't think it's a bad idea per se. JAXRS does not prohibit multiple annotations per se
(AFAIK), it's just undefined what happens. 
In CXF the first annotation is used, if you chnage the order then POST methods will be supported.
I think we can basically support 
an array of methods such as users can avoid writing filters.

I guess sometimes one can just do :

@GET method1() {invokeCommon()}
@POST method2() {invokeCommon()}

but may be in some cases that it's not possible to modify the existing interface/class by
introducing say a method 2 or even method 
3 if some clients do PUT or something


Cheers, Sergey

----- Original Message ----- 
From: "Tong, Gary (IDEAS)" <Gary.Tong@morganstanley.com>
To: <dev@cxf.apache.org>
Sent: Thursday, March 12, 2009 2:19 PM
Subject: Possibly retarded question


Is there any value in allowing a method to respond to both GET and POST requests?

Currently something like:

class Foo {
  @GET
  @POST
  public String test() {...}
}

Only responds to @GET but does not respond to @POST.

I agree that conceptually, @GET and @POST should be completely different methods.  This is
just something random that came up when 
working on our application.  One of the clients that we're using sends GET in some situations
and POST in other situations.  As 
other libraries generally handle GETs and POSTs interchangably, this wasn't an issue until
we migrated this to CXF.

In any case, it was easy enough to work around this, and I'm not even if I think it should
be changed.  Mostly just curious to hear 
the team's thoughts and see if this issue has come up before.

Cheers,
Gary

--------------------------------------------------------------------------
NOTICE: If received in error, please destroy and notify sender. Sender does not intend to
waive confidentiality or privilege. Use of 
this email is prohibited when received in error.


Mime
View raw message