From: Marc Hadley <Marc.Hadley_at_Sun.COM>
Date: Thu, 26 Apr 2007 13:08:34 -0400

On Apr 26, 2007, at 12:36 PM, Stefan Tilkov wrote:

> Assuming my resource class is implemented "cleanly", i.e. it has
> post, put, delete and get methods (that map appropriately), this
> would mean I'd have to add another post method (like the one below)
> that calls delete(), and I'd have to do that for every resource.
> But in general, I will make the decision to use this workaround for
> my complete web app, not for each and every resource class. Can
> this be done in a generic way?
>
> I'm not at all sure I like this, but how about this, inspired by [1]:
>
> @HttpMethod(DELETE) @HttpMethodOverride("X-HTTP-Method-Override",
> PUT) void delete() {...}
>
In a servlet container you could just write a servlet filter to patch
the request method based on, e.g., the X-HTTP-Method-Override header.
That seems like a cleaner solution than us adding an annotation to do
the same sort of thing. Presumably other containers have similar
capabilities ?

Marc.

>
> [1] http://code.google.com/apis/gdata/basics.html#Updating-an-entry
>
> On Apr 26, 2007, at 6:05 PM, Marc Hadley wrote:
>
>> On Apr 26, 2007, at 11:49 AM, Stefan Tilkov wrote:
>>
>>> I'm pretty sure there are strong opinions on this - just
>>> checking: do we want to support some way to do a pseudo-PUT and
>>> DELETE through POST?
>>> Even if we don't want to explicitly encourage it, do we want
>>> enable the API's users to do this? If so, how?
>>>
>> I think we already allow it using a variety of means but we don't
>> make it transparent. E.g. one could use a header or matrix URI
>> param to hold the put|delete method name and extract those in the
>> method:
>>
>> @HttpMethod(POST)
>> String doMethod(@HeaderParam("method") String method) {...}
>>
>> Is that good enough or do folks want something more automated ?
>>
>> Marc.
>>
>> ---
>> Marc Hadley <marc.hadley at sun.com>
>> CTO Office, Sun Microsystems.
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
>

---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.