[Fiware-ngsi] proposed expansion of NGSI-10

[Farkas, Lorant (NSN - HU/Budapest)]

Hi Tobias,

 

Why would you prefer POST over PUT for subscription updates? From my point of view, PUT the natural verb to do this. Subscription updates are also idempotent, as expected from PUT.

 

My understanding of REST is that whenever you change something in an existing resource - at an existing endpoint, you use POST. For instance, if you modify the NotifyCondition only, for an existing resource, then you update the resource but do not replace it. That is POST. This is equivalent to setting your status from away to online in Facebook: the resource is the same, but some of the content changes.

The only difference is if you replace the whole resource but the URL of the resource remains the same, then you could use PUT instead of POST. Like you create a brand new subscription under the same resource endpoint (in other words, the client has the control of the URL) that exists already, then you use PUT. 

The other case when PUT should be used is when you create a new resource and the client needs control of the URL (resource endpoint does not exist yet in the server).

 

The request need not be idempotent: if you POST twice that the NotifyCondition is now OnSomething and OnSomethingElse and earlier it was just OnSomething, it doesn't matter how many times you POST it (it would only be a problem if you had fields like NumValue and you would have NumValue++ in the POST).

 

Thanks & Br,

 

Lorant

 

From: fiware-ngsi-bounces at lists.fi-ware.eu [mailto:fiware-ngsi-bounces at lists.fi-ware.eu] On Behalf Of ext Tobias Jacobs
Sent: Wednesday, February 08, 2012 10:39 AM
To: Bisztray, Denes (NSN - HU/Budapest); fiware-ngsi at lists.fi-ware.eu
Subject: Re: [Fiware-ngsi] proposed expansion of NGSI-10

 

Hi Denes,

 

Thanks a lot for your propositions.

 

We have also discussed adding convenience functions for the put-operation a couple of days ago. 

One question is if the update message should really be a ContextElement (of ContextAttribute), or rather a full UpdateContextRequest, which also contains information on the updateActionType. One possibility would be to define a default updateActionType and give the possibility to change it via a parameter in the URI.

 

Why would you prefer POST over PUT for subscription updates? From my point of view, PUT the natural verb to do this. Subscription updates are also idempotent, as expected from PUT.

 

Best

Tobias

 

From: fiware-ngsi-bounces at lists.fi-ware.eu [mailto:fiware-ngsi-bounces at lists.fi-ware.eu] On Behalf Of Bisztray, Denes (NSN - HU/Budapest)
Sent: Mittwoch, 8. Februar 2012 09:52
To: fiware-ngsi at lists.fi-ware.eu
Subject: [Fiware-ngsi] proposed expansion of NGSI-10

 

Dear all,

 I checked the RESTful binding proposal created by Tobias an Laurent. I completely understand that the NGSI-10 standard allows only a mass-update of the context entities via the updateContextRequest. 

  What I propose is simple addition of update operations on the individual context elements and attributes of context elements.

-       Add a POST method to the Individual Context Element (/contextElements/{contextElementID})

-       Add a POST method to the Attribute of individual context element (/contextElements/{contextElementID}/{attributeName})

The post operation message would include the UpdateAction and note a ContextElementList, but the updated ContextElement. In case of a ContextAttribute, the updated ContextAttribute.

Correspondingly the output message would contain the ErrorCode and one ContextElementResponse structure. 

This is an addition to the standard, and I think this would ease the context information update process. What is your opinion?

Irrelevant comment: I also agree that the subscription update should be a POST method instead of the current PUT.

Best,

Dénes

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fiware.org/private/fiware-ngsi/attachments/20120208/040183bf/attachment.html>