On Apr 26, 2007, at 7:08 PM, Marc Hadley wrote:
> 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.
OK - I agree that's a good approach.
Stefan
> 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.
>
>