You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wookie.apache.org by Raido Kuli <ra...@apache.org> on 2010/05/05 20:03:21 UTC

Wookie REST API Properties HTTP methods

Hi,

In Wookie REST API Properties section are two requests:

POST {wookie}/properties 
{params: instance_params, propertyname, propertyvalue,
[is_public=true]}   

Sets a property for the specified instance. If is_public=true is set,
the property set is a Shared Data entry; otherwise it is a
Preference.   

PUT {wookie}/properties 
{params: instance_params, propertyname, propertyvalue}   

Updates the value of the specified property of the specified Widget
Instance.

---

I've noticed that POST request does both - creates and updates when
doing second request. For updating property value, there's no need for
PUT request. I guess it should be more like:

a) POST request to create new property, if exists return some HTTP error
status code - that update is not possible via POST

b) PUT request then for updating.

Currently it seems, that PUT request isn't needed at all, so I can be
and should removed if only POST will be used for creating and updating
property.


Re: Wookie REST API Properties HTTP methods

Posted by Raido Kuli <ra...@apache.org>.
Ühel kenal päeval, K, 2010-05-05 kell 19:59, kirjutas Scott Wilson:
> On 5 May 2010, at 19:03, Raido Kuli wrote:
> 
> > Hi,
> > 
> > In Wookie REST API Properties section are two requests:
> > 
> > POST {wookie}/properties 
> > {params: instance_params, propertyname, propertyvalue,
> > [is_public=true]}   
> > 
> > Sets a property for the specified instance. If is_public=true is set,
> > the property set is a Shared Data entry; otherwise it is a
> > Preference.   
> > 
> > PUT {wookie}/properties 
> > {params: instance_params, propertyname, propertyvalue}   
> > 
> > Updates the value of the specified property of the specified Widget
> > Instance.
> > 
> > ---
> > 
> > I've noticed that POST request does both - creates and updates when
> > doing second request. For updating property value, there's no need for
> > PUT request. I guess it should be more like:
> > 
> > a) POST request to create new property, if exists return some HTTP error
> > status code - that update is not possible via POST
> > 
> > b) PUT request then for updating.
> > 
> > Currently it seems, that PUT request isn't needed at all, so I can be
> > and should removed if only POST will be used for creating and updating
> > property.
> 
> Looking over the controller code you're right, POST and PUT are actually identical in their behaviour.
> 
> So the question is whether to (1) not bother with PUT, or (2) make POST and PUT behave in a more typical manner; i.e. POST should throw an exception if the property exists, and PUT should throw an exception if it doesn't. 

In my opinion only POST does the work, but it has to be said out some
where, that second request updates property value.


Re: Wookie REST API Properties HTTP methods

Posted by Scott Wilson <sc...@gmail.com>.
On 5 May 2010, at 20:51, Luciano Resende wrote:
>>> 
>> 
>> Looking over the controller code you're right, POST and PUT are actually identical in their behaviour.
>> 
>> So the question is whether to (1) not bother with PUT, or (2) make POST and PUT behave in a more typical manner; i.e. POST should throw an exception if the property exists, and PUT should throw an exception if it doesn't.
> 
> Just my 0.0002c
> 
> Usually POST would create, and then return HTTP Status code of 201
> confirming the resource was created (and might return a location URL
> of the created resource), and possible an exception when the resource
> is already available as Scott mentioned.  For PUT, it's expected just
> a HTTP status code of 200. Another aspect is that you could PUT to
> something like {wookie}/properties/propertyName (if propertyName is
> the key to a given property) and that would update the value of that
> specific key. Maybe this can help sort out if there is a need for both
> POST and PUT.

I've had a play with the PropertiesController and its pretty easy to make POST return either 201 or an exception if the property exists. Likewise for PUT to return a 404 if the property doesn't exist.

Would this cause any problems though for current implementations? The "create or update" pattern may not be pure REST but on the other hand its even easier and more resilient for clients to code to.

> 
> 
> -- 
> Luciano Resende
> http://people.apache.org/~lresende
> http://twitter.com/lresende1975
> http://lresende.blogspot.com/


Re: Wookie REST API Properties HTTP methods

Posted by Luciano Resende <lu...@gmail.com>.
On Wed, May 5, 2010 at 11:59 AM, Scott Wilson
<sc...@gmail.com> wrote:
>
> On 5 May 2010, at 19:03, Raido Kuli wrote:
>
>> Hi,
>>
>> In Wookie REST API Properties section are two requests:
>>
>> POST {wookie}/properties
>> {params: instance_params, propertyname, propertyvalue,
>> [is_public=true]}
>>
>> Sets a property for the specified instance. If is_public=true is set,
>> the property set is a Shared Data entry; otherwise it is a
>> Preference.
>>
>> PUT {wookie}/properties
>> {params: instance_params, propertyname, propertyvalue}
>>
>> Updates the value of the specified property of the specified Widget
>> Instance.
>>
>> ---
>>
>> I've noticed that POST request does both - creates and updates when
>> doing second request. For updating property value, there's no need for
>> PUT request. I guess it should be more like:
>>
>> a) POST request to create new property, if exists return some HTTP error
>> status code - that update is not possible via POST
>>
>> b) PUT request then for updating.
>>
>> Currently it seems, that PUT request isn't needed at all, so I can be
>> and should removed if only POST will be used for creating and updating
>> property.
>
> Looking over the controller code you're right, POST and PUT are actually identical in their behaviour.
>
> So the question is whether to (1) not bother with PUT, or (2) make POST and PUT behave in a more typical manner; i.e. POST should throw an exception if the property exists, and PUT should throw an exception if it doesn't.

Just my 0.0002c

Usually POST would create, and then return HTTP Status code of 201
confirming the resource was created (and might return a location URL
of the created resource), and possible an exception when the resource
is already available as Scott mentioned.  For PUT, it's expected just
a HTTP status code of 200. Another aspect is that you could PUT to
something like {wookie}/properties/propertyName (if propertyName is
the key to a given property) and that would update the value of that
specific key. Maybe this can help sort out if there is a need for both
POST and PUT.


-- 
Luciano Resende
http://people.apache.org/~lresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/

Re: Wookie REST API Properties HTTP methods

Posted by Scott Wilson <sc...@gmail.com>.
On 5 May 2010, at 19:03, Raido Kuli wrote:

> Hi,
> 
> In Wookie REST API Properties section are two requests:
> 
> POST {wookie}/properties 
> {params: instance_params, propertyname, propertyvalue,
> [is_public=true]}   
> 
> Sets a property for the specified instance. If is_public=true is set,
> the property set is a Shared Data entry; otherwise it is a
> Preference.   
> 
> PUT {wookie}/properties 
> {params: instance_params, propertyname, propertyvalue}   
> 
> Updates the value of the specified property of the specified Widget
> Instance.
> 
> ---
> 
> I've noticed that POST request does both - creates and updates when
> doing second request. For updating property value, there's no need for
> PUT request. I guess it should be more like:
> 
> a) POST request to create new property, if exists return some HTTP error
> status code - that update is not possible via POST
> 
> b) PUT request then for updating.
> 
> Currently it seems, that PUT request isn't needed at all, so I can be
> and should removed if only POST will be used for creating and updating
> property.

Looking over the controller code you're right, POST and PUT are actually identical in their behaviour.

So the question is whether to (1) not bother with PUT, or (2) make POST and PUT behave in a more typical manner; i.e. POST should throw an exception if the property exists, and PUT should throw an exception if it doesn't.