Possibly retarded question

["Tong, Gary (IDEAS)" <Ga...@morganstanley.com>]

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.

Re: Multiple HTTP methods per method in JAXRS (Re: Possibly retarded question)

[Sergey Beryozkin <sb...@progress.com>]

> > Don't make Roy Fielding have to come around to your house!

This is funny :-)

> I think if you use GET and POST on the same URI  then you are
> innappropriately 'crossing the streams' and making it ambiguous
> as to whether the invocation is idempotent or not.

That is true.
That said, one way of looking at having say both GET and POST at the same method is that a user is saying : I know
that some new clients call GET and while others (legacy ones) call POST (with POST clients in this example providing an unexpected 
HTTP method), which I reckon what Gary is after in this case. Typically users write filters to do it or provide multiple methods 
delegating to a common one. Supporting multiple HTTP methods on a single method would be just another way to achieve the same fairly 
specific goal.

Cheers, Sergey

----- Original Message ----- 
From: "Oisin Hurley" <oi...@gmail.com>
To: <de...@cxf.apache.org>
Sent: Thursday, March 12, 2009 4:12 PM
Subject: Re: Multiple HTTP methods per method in JAXRS (Re: Possibly retarded question)


>> 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.
>
> I think if you use GET and POST on the same URI  then you are
> innappropriately 'crossing the streams' and making it ambiguous
> as to whether the invocation is idempotent or not.
>
> Don't make Roy Fielding have to come around to your house!
>
> --oh 

Re: Multiple HTTP methods per method in JAXRS (Re: Possibly retarded question)

[Oisin Hurley <oi...@gmail.com>]

> 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.

I think if you use GET and POST on the same URI  then you are
innappropriately 'crossing the streams' and making it ambiguous
as to whether the invocation is idempotent or not.

Don't make Roy Fielding have to come around to your house!

 --oh

Multiple HTTP methods per method in JAXRS (Re: Possibly retarded question)

[Sergey Beryozkin <sb...@progress.com>]

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)" <Ga...@morganstanley.com>
To: <de...@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.