Exactly. What I look for is some kind of proposal/argument/solution.
I proposed the "replace all" solution, because that is idempontent when PUT is used.
Martin argued that it is too radical, however he did not read my mails properly. When a query is used, it can be easily achieved (metadata:source, metadata:provider, etc) to get our desired element back and only update that one.
When we have the contextElement or contextElements level, I wonder what could be the solution. Or that is what Stephan proposed?
Best,
Dénes
From: ext Tobias Jacobs [mailto:Tobias.Jacobs at neclab.eu]
Sent: Wednesday, February 29, 2012 4:01 PM
To: Bisztray, Denes (NSN - HU/Budapest); Martin Bauer; ext Haller, Stephan; Farkas, Lorant (NSN - HU/Budapest); Zamani Farahani, Armin; fiware-ngsi at lists.fi-ware.eu; Tschirschnitz, Fabian
Subject: RE: [Fiware-ngsi] proposed expansion of NGSI-10
Hi Denes,
"it replaces the value and metadata of the existing attributes with the same name;"
I think you identified an important point: By the specified semantics of the updateActionType "update" is not possible at all to update a specific instance of an attribute value, because the different instances all have the same name.
So at this point we need to deviate from what is written in the standard, right?
Best
Tobias
From: Bisztray, Denes (NSN - HU/Budapest) [mailto:denes.bisztray at nsn.com]
Sent: Mittwoch, 29. Februar 2012 15:30
To: Martin Bauer; ext Haller, Stephan; Tobias Jacobs; Farkas, Lorant (NSN - HU/Budapest); Zamani Farahani, Armin; fiware-ngsi at lists.fi-ware.eu; Tschirschnitz, Fabian
Subject: RE: [Fiware-ngsi] proposed expansion of NGSI-10
I understand both of you, and your viewpoint. However, this is not the problem of the convenience method.
If you look at the official spec (sec 5.4.6.1, pg 22), you will find the following text:
"it replaces the value and metadata of the existing attributes with the same name;"
If we figure out what this means exactly, we can implement it in the convenience methods and every level.
Please someone the following table:
request
System
one attribute of same name
Multiple attribute of same name
One attribute of same name
replace
?
Multiple attribute of same name
?
?
Before someone would say, oh dependent on the metadata, I'd answer, unfortunately we cannot count on it, as one may ask, which metadata.
Best,
Dénes
From: ext Martin Bauer [mailto:Martin.Bauer at neclab.eu]
Sent: Wednesday, February 29, 2012 3:18 PM
To: Bisztray, Denes (NSN - HU/Budapest); ext Haller, Stephan; Tobias Jacobs; Farkas, Lorant (NSN - HU/Budapest); Zamani Farahani, Armin; fiware-ngsi at lists.fi-ware.eu; Tschirschnitz, Fabian
Subject: RE: [Fiware-ngsi] proposed expansion of NGSI-10
Hi Denes,
The convenience method should not harm the operation of the overall system, so the default operation
should not be "overwrite all other values".
As Stephan mentioned, if you have two sensors that use the convenience methods for updating, you should
keep both values and not have one constantly overwrite the other. You would get oscillating results, possibly
differing significantly in quality, so this would result in poor service for querying applications.
Best regards,
Martin
------------------------------------------
Dr. Martin Bauer
Senior Researcher
NEC Europe Ltd.
NEC Laboratories Europe
Software & Services Research Division
Kurfürsten-Anlage 36
D-69115 Heidelberg
Tel: +49/ (0)6221/4342-168
Fax: +49/ (0)6221/4342-155
E-Mail: Martin.Bauer at neclab.eu <mailto:Martin.Bauer at neclab.eu>
http://www.nw.neclab.eu <http://www.nw.neclab.eu/>
*************************************************************
NEC Europe Limited
Registered Office: NEC House, 1 Victoria Road, London W3 6BL
Registered in England 2832014
From: Bisztray, Denes (NSN - HU/Budapest) [mailto:denes.bisztray at nsn.com]
Sent: Wednesday, February 29, 2012 3:04 PM
To: ext Haller, Stephan; Tobias Jacobs; Martin Bauer; Farkas, Lorant (NSN - HU/Budapest); Zamani Farahani, Armin; fiware-ngsi at lists.fi-ware.eu; Tschirschnitz, Fabian
Subject: RE: [Fiware-ngsi] proposed expansion of NGSI-10
Hi Stephan,
1. Yes, but not at the /{attributeName} level. You can add new attributes at the /{contextElement} level. If the same name is already present then we will have multiple attributes.
2. No, you can query with /{attributeName}/?{metadataName}={metadataValue}
3. Ok.
Best,
Dénes
From: ext Haller, Stephan [mailto:stephan.haller at sap.com]
Sent: Wednesday, February 29, 2012 3:02 PM
To: Bisztray, Denes (NSN - HU/Budapest); ext Tobias Jacobs; Martin Bauer; Farkas, Lorant (NSN - HU/Budapest); Zamani Farahani, Armin; fiware-ngsi at lists.fi-ware.eu; Tschirschnitz, Fabian
Subject: RE: [Fiware-ngsi] proposed expansion of NGSI-10
Dénes,
If I look at your changed table, then
1. There is no possibility to create/append an attribute!
2. If multiple attributes with the same name exist, it becomes impossible to update just that attribute. This is a problem if we have several independent sensors providing different values for the same attribute (like in the location and room temperature examples given before)
3. POST always fails (like in our option 2). Then I think a return value of 405 is more suitable
Regards,
-Stephan
From: Bisztray, Denes (NSN - HU/Budapest) [mailto:denes.bisztray at nsn.com]
Sent: Mittwoch, 29. Februar 2012 14:46
To: Haller, Stephan; ext Tobias Jacobs; Martin Bauer; Farkas, Lorant (NSN - HU/Budapest); Zamani Farahani, Armin; fiware-ngsi at lists.fi-ware.eu; Tschirschnitz, Fabian
Subject: RE: [Fiware-ngsi] proposed expansion of NGSI-10
Hi all,
PUT vs POST
Two notes before the table. I attached the doc with the following included, for details please have a look at it.
Otherwise:
POST: not available for /{attributeName}
PUT: replace, working is the following
Input message: set of attributes with the same name.
Case 1: the /{attributeName} is called
Result: all attributes are replaced with the attributes in the input message. Replace should be replace, right?
Case 2: an /{attributeName}/?{metadataName}={metadataValue} query is used
Result:
a) There is a set of resultant ContextAttributes (with the same name): all of them are replaced with the incoming set.
b) No result: Fail 404
Otherwise, using the table.
Operation
Attribute w/o meta data
Attribute with meta data
non-existent
exact match
multiple match
non-existent
attribute exists, but different meta data
exact match (name and meta data)
PUT
Fail 404
Replace
Replace all
Fail 404
Replace all
Replace all
POST
n/a, Fail 403
n/a, Fail 403
n/a, Fail 403
n/a, Fail 403
n/a, Fail 403
n/a, Fail 403
My reasons are the following:
- It is possible that not (or not only) the attribute value is updated, but the metadata.
- We do not stray too far away from the standard (no append on attribute level)
- Simple
As a last thought, this is only when addressing the /{contextAttribute}
Best,
Dénes
è We need to specify this in more detail. One possibility would be as follows:
PUT = Replace, fails if non-existent or under-specified
POST = Create/Append, fails if under-specified or already existing
In more detail, we have to make a distinction if meta data is given in the request or not:
Operation
Attribute w/o meta data
Attribute with meta data
non-existent
exact match
multiple match
non-existent
attribute exists, but different meta data
exact match (name and meta data)
PUT
Fail 404
Replace
Fail 409
Fail 404
Fail 404
Replace
POST
Create
Fail 405 (allow PUT)
Fail 409*
Create
Append
Fail 405 (allow PUT)
* If we want a different behaviour in this case, we would neet to auto-generate meta data!
Thinking of it, I believe we could actually simplify the whole thing:
Operation
Attribute w/o meta data
Attribute with meta data
non-existent
single match
multiple match
non-existent
attribute exists, but different meta data
exact match (name & meta data)
PUT
Create
Replace
Fail 409
Create
Append
Replace
POST
Create
Replace
Fail 409*
Create
Append
Replace
If we go for this second option, we could even eliminate one of the two operations as they have exactly the same behaviour.
1. MultiAttribute-gate
I don't see the point why should we have an enforced ID metadata. Why the query not good? You can query the ID, but also Provider, source whatever you are interested in.
è In the GET case, if there are several attributes with a matching name, the complete list should be returned. Query-parameters (like "?ID=xxx") can be used to further restricted the items returned. Any I also agree that it should be possible to query for ID or any other (meta data) parameter.
2. AttributeDomain and Attribute distinction
Can we agree on having a strong distinction (i.e. attributes/ and attributeDomains/ in the RESTful binding)? Or should we embrace the chaos J ?
è Agree.
If we can reach some kind of agreement, I'll implement these into the doc as soon as the agreement is acknowledged.
Best,
Dénes
From: ext Tobias Jacobs [mailto:Tobias.Jacobs at neclab.eu]
Sent: Wednesday, February 29, 2012 9:51 AM
To: Bisztray, Denes (NSN - HU/Budapest); Martin Bauer; Farkas, Lorant (NSN - HU/Budapest); ext Haller, Stephan; Zamani Farahani, Armin; fiware-ngsi at lists.fi-ware.eu
Subject: RE: [Fiware-ngsi] proposed expansion of NGSI-10
Hi,
Okay, then I think we have to enforce an ID to be provided with the updateContext operation (with actiontype update).
"Append" operations without an ID should lead the system to assign the ID, right?
Best
Tobias
From: Bisztray, Denes (NSN - HU/Budapest) [mailto:denes.bisztray at nsn.com]
Sent: Mittwoch, 29. Februar 2012 07:35
To: Martin Bauer; Tobias Jacobs; Farkas, Lorant (NSN - HU/Budapest); ext Haller, Stephan; Zamani Farahani, Armin; fiware-ngsi at lists.fi-ware.eu
Subject: RE: [Fiware-ngsi] proposed expansion of NGSI-10
Hi all,
I'm not in favor of it either. When the /{attributeName} is queried, all values should be replied, and as previously mentined we should have /{attributeName}/?{metadataName}={metadataValue} queries to reach individual attributes of the same name.
Best,
Dénes
From: ext Martin Bauer [mailto:Martin.Bauer at neclab.eu]
Sent: Tuesday, February 28, 2012 11:52 PM
To: Tobias Jacobs; Farkas, Lorant (NSN - HU/Budapest); ext Haller, Stephan; Bisztray, Denes (NSN - HU/Budapest); Zamani Farahani, Armin; fiware-ngsi at lists.fi-ware.eu
Subject: RE: [Fiware-ngsi] proposed expansion of NGSI-10
Hi all,
I have a problem with a "default value" as it is not clear which value should be used as a default value - the latest one updated? the one with the best quality values? (what is best in this context?) an arbitrary one? the one provided by a certain user?
With a centralized system, we may be able to have a consistent default value, but with a distributed system (e.g. NEC's Isis in a cluster setting), this could be difficult as a different set of values for the same attribute may be stored on different nodes, which could still be accessed by a single query. Client applications can also use different nodes for accessing the information. This may lead to the situation that clients get a different view simply depending on which node they use.
Due to the above, I am not in favour of a "default value".
Best regards,
Martin
------------------------------------------
Dr. Martin Bauer
Senior Researcher
NEC Europe Ltd.
NEC Laboratories Europe
Software & Services Research Division
Kurfürsten-Anlage 36
D-69115 Heidelberg
Tel: +49/ (0)6221/4342-168
Fax: +49/ (0)6221/4342-155
E-Mail: Martin.Bauer at neclab.eu
http://www.nw.neclab.eu <http://www.nw.neclab.eu/>
*************************************************************
NEC Europe Limited
Registered Office: NEC House, 1 Victoria Road, London W3 6BL
Registered in England 2832014
From: fiware-ngsi-bounces at lists.fi-ware.eu [mailto:fiware-ngsi-bounces at lists.fi-ware.eu] On Behalf Of Tobias Jacobs
Sent: Tuesday, February 28, 2012 6:03 PM
To: Farkas, Lorant (NSN - HU/Budapest); ext Haller, Stephan; Bisztray, Denes (NSN - HU/Budapest); Zamani Farahani, Armin; fiware-ngsi at lists.fi-ware.eu
Subject: Re: [Fiware-ngsi] proposed expansion of NGSI-10
Hi all,
I agree with Stephan that hiding values in the metadata is a rather confusing approach, and also uses the data structures differently than intended.
On the other hand the GET on attribute resources is supposed to be a simple convenience function and it is apparently more simple to get only one value back than to get multiple values.
One possibility is to return only the default attribute value when no parameter in the URL is specified, and introduce an optional parameter "?instances=all" which indicates that the application is interested in all available values.
In general, how about the idea that the system has a "default" value instance for each attribute. This default value is updated whenever there is an update operation (with actiontype update) without ID specified. And in case of an append operation without ID, the ID is created by the system and returned in the UpdateContextResponse.
(again, note that the preceding paragraph is more related to NGSI in general than to the RESTful binding)
Best
Tobias
From: Farkas, Lorant (NSN - HU/Budapest) [mailto:lorant.farkas at nsn.com]
Sent: Dienstag, 28. Februar 2012 14:24
To: ext Haller, Stephan; Bisztray, Denes (NSN - HU/Budapest); Tobias Jacobs; Zamani Farahani, Armin; fiware-ngsi at lists.fi-ware.eu
Subject: RE: [Fiware-ngsi] proposed expansion of NGSI-10
Hi,
1. Right, in your case it makes sense. Still, it should be possible to "hide" values. For instance, one of the sensor providers might not want to reveal data to this app. Then just 3 values should be returned. But of course this is different functionality, different GE (data access policy, I believe). Or retrieving one of the sensor data might be more expensive (my case: triangulation): this value would be returned only to "premium apps".
2. OK
Br,
Lorant
From: ext Haller, Stephan [mailto:stephan.haller at sap.com]
Sent: Tuesday, February 28, 2012 1:34 PM
To: Farkas, Lorant (NSN - HU/Budapest); Bisztray, Denes (NSN - HU/Budapest); ext Tobias Jacobs; Zamani Farahani, Armin; fiware-ngsi at lists.fi-ware.eu
Subject: RE: [Fiware-ngsi] proposed expansion of NGSI-10
Well, the app might be interested in all values. Take the example I used before, with one room and 4 sensors, one in each corner. An app might be interested in all temperature values in order to compute the average.
I believe we shouldn't make any general assumption what apps want and what not. The API needs to be able to provide all the data as well as single values based on query parameters.
Secondly, it is very counter-intuitive to "hide" attribute values inside meta-data.
Regards,
-Stephan
From: Farkas, Lorant (NSN - HU/Budapest) [mailto:lorant.farkas at nsn.com]
Sent: Dienstag, 28. Februar 2012 13:25
To: Bisztray, Denes (NSN - HU/Budapest); ext Tobias Jacobs; Haller, Stephan; Zamani Farahani, Armin; fiware-ngsi at lists.fi-ware.eu
Subject: RE: [Fiware-ngsi] proposed expansion of NGSI-10
Hello,
Have not read all the e-mails carefully, I have the following example in my head: location can be provided by 3 sources, the GPS, by the cellular core network (which VLR is the phone registered), cellular radio network (triangulation between base stations). I would handle these 3 sources by the ContextMetadata array. For instance, the ContextAttribute in this case could be:
Name: location
Type: string
ContextValue: depends
ContextMetadata[0]:
name: "gps"
type: "WGS84"
value: "45.3 North, 34.4 East, 10 m accuracy"
ContextMetadata[1]:
name: "cellular core"
type: "location area"
value: "North-East Hungary" (or can be a data structure describing a poligon or a circle and radius)
ContextMetadata[2]:
type: "cellular RAN"
type: "cellular RAN"
value: "45.3 North, 34.4 East, 50 m accuracy"
If we get a 4th source (e.g. road camera), there will be a 4th Contextmetadata array element describing this. The provider of the source would append this new source to the ContextAttribute sub-resource.
So I would go for the following:
1. One single attribute name. If there is additional provider, this can be handled through the ContextMetadata table. The app is not interested in 3 locations or 3 temperatures, it would get confused.
2. Optionally parameters in the query like "?accuracy=...&freshness=...;" would indicate from which source the ContextValue should be inserted in the response.
3. Machinery in the background based on some criteria (e.g. does the requesting app pay, how expensive is for the cellular network to triangulate etc) give back just one value.
4. GET to the resource will not give back necessarily the ContextMetadata array to the app, app does not need to know by which means I provide the location data
Thanks & Br,
Lorant
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: Tuesday, February 28, 2012 1:19 PM
To: ext Tobias Jacobs; ext Haller, Stephan; Zamani Farahani, Armin; fiware-ngsi at lists.fi-ware.eu
Subject: Re: [Fiware-ngsi] proposed expansion of NGSI-10
Hi All,
We indeed should make the ContextMetadata field compulsory, when ContextAttributes of same name exist as proposed by Armin.
I have the following thoughts on the two alternatives proposed by Tobias:
- Have ETSI M2M-like containers as mentioned by Martin, BUT the ID comes from the ContextMetadata. However in this case we have to decide which metadata to use. This can be impossible, because in one case the differentiating factor is the Source (Martin's location example), but maybe in another case the timestamp (time series data).
- Have an optional URI parameter that is proposed by Tobias is nice, and with this case we can address multiple metadata types. In this scenario when the /{attributeName} is queried, the full list is given back, but one can have a /{attributeName}/?{ContextMetadataName}={ContextMetadataValue} query. This way we can say /Location/?Source=GPS.
NSN started to implement the RESTful binding, so a decision and agreement on this topic is welcome as soon as possible.
Best,
Dénes
From: ext Tobias Jacobs [mailto:Tobias.Jacobs at neclab.eu]
Sent: Tuesday, February 28, 2012 11:37 AM
To: Bisztray, Denes (NSN - HU/Budapest); ext Haller, Stephan; Zamani Farahani, Armin; fiware-ngsi at lists.fi-ware.eu
Subject: RE: [Fiware-ngsi] proposed expansion of NGSI-10
Hi Denes,
1. Same named attributes
The idea is that the value of an attribute could be provided by several providers. For example, the location of a context entity could be provided both by a GPS device and by a camera which detects the entity.
Note that e.g. also ETSI M2M has this concept; there "container" resources have multiple "contentInstance" subresources.
I completely understand this concern. However, the RESTful binding is flawed if we have similar {attributeName} URIs for different Attributes.
I see two possible solutions [also in response to Armin's concern]:
I) Go for an ETSI-like solution and make a subresource for each instance of the attribute value
II) Return all instances of the attribute value by in the case of standard GET, and introduce an optional URI parameter (like "?Id=132") for specifying a specific instance.
I prefer possibility II as it keeps compatibility with simple systems where only one instance of each attribute value exists.
2. Attribute/domain name distinction
I am not sure if we need a strong distinction between attributes and attribute domains - in the NGSI-10 specs there is no such distinction.
For example, the request of the QueryContext operation contains a string list called "AttributeList", and each of these strings can either represent an attribute or an attribute domain.
If we define distinct operations for queries to attributes and for attribute domains, we require the requestor to know whether the request refers to a single attribute or to a domain. Do we really want that?
What would be the problem with this approach? For me its evident that we should distinguish them, I would like to see the other side, what are the reasons for not distinguishing them?
First, let me emphasize that this is an issue of NGSI-10 in general, and not of the RESTful binding in particular. From my point of view this is implies that we rather need a reason for distinguishing between them (because in NGSI they are unified).
I have to admit that I neither know strong reasons for distinguishing them, nor for not to distinguish them. Maybe there are situations where applications do not know whether an attribute name refers to a domain or to a single attribute, but I have not found good examples up to now.
Best
Tobias
From: Bisztray, Denes (NSN - HU/Budapest) [mailto:denes.bisztray at nsn.com]
Sent: Dienstag, 28. Februar 2012 11:13
To: Tobias Jacobs; ext Haller, Stephan; Zamani Farahani, Armin; fiware-ngsi at lists.fi-ware.eu
Subject: RE: [Fiware-ngsi] proposed expansion of NGSI-10
Hi Tobias, and all
From: ext Tobias Jacobs [mailto:Tobias.Jacobs at neclab.eu]
Sent: Tuesday, February 28, 2012 10:25 AM
To: Bisztray, Denes (NSN - HU/Budapest); ext Haller, Stephan; Zamani Farahani, Armin; fiware-ngsi at lists.fi-ware.eu
Subject: RE: [Fiware-ngsi] proposed expansion of NGSI-10
Hi Stefan, Denes, all
1. Same named attributes
The idea is that the value of an attribute could be provided by several providers. For example, the location of a context entity could be provided both by a GPS device and by a camera which detects the entity.
Note that e.g. also ETSI M2M has this concept; there "container" resources have multiple "contentInstance" subresources.
I completely understand this concern. However, the RESTful binding is flawed if we have similar {attributeName} URIs for different Attributes.
2. Attribute/domain name distinction
I am not sure if we need a strong distinction between attributes and attribute domains - in the NGSI-10 specs there is no such distinction.
Still, if we have similar named doman and attribute the problem is there. I would go for the "strict" distinction.
For example, the request of the QueryContext operation contains a string list called "AttributeList", and each of these strings can either represent an attribute or an attribute domain.
If we define distinct operations for queries to attributes and for attribute domains, we require the requestor to know whether the request refers to a single attribute or to a domain. Do we really want that?
What would be the problem with this approach? For me its evident that we should distinguish them, I would like to see the other side, what are the reasons for not distinguishing them?
Best,
Dénes
From: Bisztray, Denes (NSN - HU/Budapest) [mailto:denes.bisztray at nsn.com]
Sent: Dienstag, 28. Februar 2012 09:58
To: ext Haller, Stephan; Tobias Jacobs; Zamani Farahani, Armin; fiware-ngsi at lists.fi-ware.eu
Subject: RE: [Fiware-ngsi] proposed expansion of NGSI-10
Hi All,
1. Same named attributes
I don't see any point in similar named attributes or entities either. Similar to the ContextElementResponse structure, I created a ContextAttributeResponse structure. And when update is called, similar to the updateContextResponse (page 22, sec 5.4.6.2 ) a list of ContextAttributeResponse is sent back with the errorcodes attribute-by-attribute. And the ones that are already present will fail.
2. Attribute/domain name distinction
This is a real problem apparently. I propose the following change in the restful-binding doc.
/contextElements/{contextElementId}/attributes/{attributeName}
/contextElements/{contextElementId}/domains/{attributeDomainName}
And same goes for the contextElementTypes.
I attached the version that contains the changes of point 1 in this mail.
Best,
Dénes
From: ext Haller, Stephan [mailto:stephan.haller at sap.com]
Sent: Tuesday, February 28, 2012 9:44 AM
To: Tobias Jacobs; Bisztray, Denes (NSN - HU/Budapest); Zamani Farahani, Armin; fiware-ngsi at lists.fi-ware.eu
Subject: RE: [Fiware-ngsi] proposed expansion of NGSI-10
Martin, Tobias,
This is not really REST-like. Additionally, the spec seems flawed:
(1) Allowing several attributes with the same name doesn't make any sense to us whatsoever. What is the reasoning behind it?
(2) If we need an ID meta data attribute to resolve this, then the MetaData parameter shouldn't be optional, and would need at least one element (i.e., the ID).
(3) How should one react if a request for an attribute doesn't include the meta data? It is impossible to resolve if there are several attributes with the same name. Should an error be returned, or some default (e.g., the first one) be returned?
The second question we raised is still unanswered. It is impossible to distinguish just from the URL if the operation is intended on an attribute or on an attribute domain. See the following to URLs:
/contextElements/{contextElementID}/foo
/contextElements/{contextElementID}/bar
Are foo and bar attribute names or attribute domain names??
Again, this seems to us like a flaw in the spec.
Regards,
Stephan, Armin, Fabian
From: fiware-ngsi-bounces at lists.fi-ware.eu [mailto:fiware-ngsi-bounces at lists.fi-ware.eu] On Behalf Of Tobias Jacobs
Sent: Freitag, 24. Februar 2012 15:02
To: Bisztray, Denes (NSN - HU/Budapest); Zamani Farahani, Armin; fiware-ngsi at lists.fi-ware.eu
Subject: Re: [Fiware-ngsi] proposed expansion of NGSI-10
Hi Armin, Fabian, Denes
/contextElements/{contextElementID}/{attributeName}
For the request of attributes of an context element all four relevant HTTP verbs are defined. For PUT it is also allowed to have multiple attributes with the same name. How can we then determine which one of the multiple attributes is meant when a POST request is sent to update an attribute value?
I would say this is present in the official spec, it simply says "Note: this may result in multiple attributes with the same name;" but does not give a resolution mechanism. Thanks for pointing it out. Do you have any solution idea? Maybe we could send an error message back when someone PUTs multiple attributes with similar names.
The intended solution is to give attribute "versions" an ID using metadata. In Section 5.5.3 of the official specs you can see that "ID" is one of the reserved metadata name strings.
Best regards
Martin and 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: Freitag, 24. Februar 2012 07:50
To: ext Zamani Farahani, Armin; fiware-ngsi at lists.fi-ware.eu
Subject: Re: [Fiware-ngsi] proposed expansion of NGSI-10
Hi Armin and Fabian,
/contextElements/{contextElementID}/{attributeName}
For the request of attributes of an context element all four relevant HTTP verbs are defined. For PUT it is also allowed to have multiple attributes with the same name. How can we then determine which one of the multiple attributes is meant when a POST request is sent to update an attribute value?
I would say this is present in the official spec, it simply says "Note: this may result in multiple attributes with the same name;" but does not give a resolution mechanism. Thanks for pointing it out. Do you have any solution idea? Maybe we could send an error message back when someone PUTs multiple attributes with similar names.
/contextElements/{contextElementID}/{attributeDomainName}
In contrast to the context attributes request, only the HTTP verb GET is allowed. Since the path is the same and PUT, POST and DELETE are not allowed for attribute domain requests, how can we distinguish between context attribute and attribute domain requests for e.g. POST, to reject or handle the request?
The situation with this is different. The official spec does not define the four operations either {attributeName} or {attributeDomain} only GET. I proposed those convenience methods for {attributeName} and did not take the {attributeDomain} into account as I did not have time and did not found it very important.
Best,
Dénes
From: fiware-ngsi-bounces at lists.fi-ware.eu <mailto:fiware-ngsi-bounces at lists.fi-ware.eu> [mailto: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: Montag, 13. Februar 2012 09:13
To: ext Tobias Jacobs; Farkas, Lorant (NSN - HU/Budapest); fiware-ngsi at lists.fi-ware.eu <mailto:fiware-ngsi at lists.fi-ware.eu>
Subject: Re: [Fiware-ngsi] proposed expansion of NGSI-10
Hi Tobias,
Ok, its fine by me. Can you switch these two in the doc?
Best,
Dénes
From: ext Tobias Jacobs [mailto:Tobias.Jacobs at neclab.eu <mailto:Tobias.Jacobs at neclab.eu> ]
Sent: Friday, February 10, 2012 4:31 PM
To: Bisztray, Denes (NSN - HU/Budapest); Farkas, Lorant (NSN - HU/Budapest); fiware-ngsi at lists.fi-ware.eu <mailto:fiware-ngsi at lists.fi-ware.eu>
Subject: RE: [Fiware-ngsi] proposed expansion of NGSI-10
Hi Denes,
I am afraid PUT cannot be used for appends, because appending is not idempotent, but PUT is required to be.
Using PUT for updates and POST for appending would work out, but then this would contradict the OMA rule of using POST for partial updates...
By the way, could you please give me write access to the SVN?
Best
Tobias
From: Bisztray, Denes (NSN - HU/Budapest) [mailto:denes.bisztray at nsn.com <mailto:denes.bisztray at nsn.com> ]
Sent: Donnerstag, 9. Februar 2012 14:53
To: Tobias Jacobs; Farkas, Lorant (NSN - HU/Budapest); fiware-ngsi at lists.fi-ware.eu <mailto:fiware-ngsi at lists.fi-ware.eu>
Subject: RE: [Fiware-ngsi] proposed expansion of NGSI-10
Hi Tobias,
Here goes the doc. Apparently I mixed up, the Append is the PUT (since the Context Attribute or Element does not exists it creates new) and the Update is the POST.
I also uploaded this to the SVN.
https://forge.fi-ware.eu/scmrepos/svn/iot/trunk/documents/Ngsi10-RestfulBinding-Draft.docx <https://forge.fi-ware.eu/scmrepos/svn/iot/trunk/documents/Ngsi10-RestfulBinding-Draft.docx>
Best,
Dénes
From: ext Tobias Jacobs [mailto:Tobias.Jacobs at neclab.eu] <mailto:[mailto:Tobias.Jacobs at neclab.eu]>
Sent: Thursday, February 09, 2012 2:02 PM
To: Bisztray, Denes (NSN - HU/Budapest); Farkas, Lorant (NSN - HU/Budapest); fiware-ngsi at lists.fi-ware.eu <mailto:fiware-ngsi at lists.fi-ware.eu>
Subject: RE: [Fiware-ngsi] proposed expansion of NGSI-10
Sounds like a good idea.
So I wait for you document and then update the binding with the other points discussed in the last couple of days.
Best
Tobias
From: Bisztray, Denes (NSN - HU/Budapest) [mailto:denes.bisztray at nsn.com <mailto:denes.bisztray at nsn.com> ]
Sent: Donnerstag, 9. Februar 2012 13:57
To: Tobias Jacobs; Farkas, Lorant (NSN - HU/Budapest); fiware-ngsi at lists.fi-ware.eu <mailto:fiware-ngsi at lists.fi-ware.eu>
Subject: RE: [Fiware-ngsi] proposed expansion of NGSI-10
Hi Tobias,
I figured out a solution to the POST/PUT question in case of /{contextElementId} (and possibly /{subscriptionId}) cases.
We omit the UpdateActionType element, and
- PUT is for UpdateActionType::Update
- POST is for UpdateActionType::Append
I'm currently working on the document with the corresponding "new" input and output messages. I'll send it hopefully today.
Best,
Dénes
From: ext Tobias Jacobs [mailto:Tobias.Jacobs at neclab.eu] <mailto:[mailto:Tobias.Jacobs at neclab.eu]>
Sent: Thursday, February 09, 2012 1:52 PM
To: Bisztray, Denes (NSN - HU/Budapest); Farkas, Lorant (NSN - HU/Budapest); fiware-ngsi at lists.fi-ware.eu <mailto:fiware-ngsi at lists.fi-ware.eu>
Subject: RE: [Fiware-ngsi] proposed expansion of NGSI-10
Hi Denes, Lorant, all,
thanks a lot for providing the information on REST verbs. Now I am more convinced to use POST for subscription updates.
- UpdateContextInformation at /contextElements remains a POST
agreed.
- New subscription creation at /subscriptions remains a POST
agreed.
- UpdateSubscription at /{subscriptionId} can be both POST and PUT depending on the update: if its complete rewrite it is a PUT, if a partial it is a POST.
I would say it is always a POST, because the complete rewrite is only a very special case, and in general the operation is a partial update.
- Creation of a Context Element at /{contextElementId} is a PUT
- Updating a Context Element at /{contextElementId} can be both POST and PUT with the similar reasoning, i.e. complete rewrite vs partial update
In NGSI 10 there is no particular operation that creates a contextElement. You can simply use the updateContext operation to push attribute values into the context management component even if it is the first time the context management component ever hears about a ContextElement with that ID. In other words, there is no distinction between creating and updating context information in NGSI 10 from the Context Provider Component point of view.
I would therefore recommend to only allow POST at /{contextElementId} and /{contextElementId}/attributeName.
However we have a little problem here.
At the partial update POST at subordinate resource (i.e. /{contextElementId}) the mandatory fields of the involved data structures are still mandatory, and as such they have to be included. So I wonder how can we have a partial update when we have to send possibly all information again, like in a complete rewrite...
What do you think of this?
Which mandatory data structures do you mean? If the request body is an instance of ContextElement as discussed in a previous email (see below), then the only mandatory field is the EntityId (however the Id is already encoded in the access URI, so we might not require it in the body). Into this ContextElement one only puts the ContextAttributes and DomainMetadata which one wishes to update.
Best regards
Tobias
From: Bisztray, Denes (NSN - HU/Budapest) [mailto:denes.bisztray at nsn.com <mailto:denes.bisztray at nsn.com> ]
Sent: Donnerstag, 9. Februar 2012 09:50
To: Tobias Jacobs; Farkas, Lorant (NSN - HU/Budapest); fiware-ngsi at lists.fi-ware.eu <mailto:fiware-ngsi at lists.fi-ware.eu>
Subject: RE: [Fiware-ngsi] proposed expansion of NGSI-10
Hi Tobias,
I checked the OMA Spec for RESTful APIs (both that was sent by Lorant), and we have the following:
- POST is for
o Creation of a subordinate resource addressed at the parent resource (i.e. creation of a ContextElement posted to the /contextElements) - (Sec 5/2.c and Sec 5.5)
o Partial update of a resource (Sec 5/2.c)
o Partial update of one or more subordinate resources (Sec 5/2.c)
- PUT is for
o If points to an existing resource, it does a complete update, which is idempotent.
o If points to a nonexistent resource, it creates it.
This translates to the following:
- UpdateContextInformation at /contextElements remains a POST
- New subscription creation at /subscriptions remains a POST
- UpdateSubscription at /{subscriptionId} can be both POST and PUT depending on the update: if its complete rewrite it is a PUT, if a partial it is a POST.
- Creation of a Context Element at /{contextElementId} is a PUT
- Updating a Context Element at /{contextElementId} can be both POST and PUT with the similar reasoning, i.e. complete rewrite vs partial update
However we have a little problem here.
At the partial update POST at subordinate resource (i.e. /{contextElementId}) the mandatory fields of the involved data structures are still mandatory, and as such they have to be included. So I wonder how can we have a partial update when we have to send possibly all information again, like in a complete rewrite...
What do you think of this?
Best,
Dénes
From: ext Tobias Jacobs [mailto:Tobias.Jacobs at neclab.eu] <mailto:[mailto:Tobias.Jacobs at neclab.eu]>
Sent: Wednesday, February 08, 2012 1:57 PM
To: Farkas, Lorant (NSN - HU/Budapest); Bisztray, Denes (NSN - HU/Budapest); fiware-ngsi at lists.fi-ware.eu <mailto:fiware-ngsi at lists.fi-ware.eu>
Subject: RE: [Fiware-ngsi] proposed expansion of NGSI-10
Hi Lorant,
Thanks for your fast reply.
Up to now I had assumed that PUT is used for changing an existing resource (not matter if it is a complete renewal or a partial change) and POST is used for creating new resources.
Some random links about the question:
http://www.ibm.com/developerworks/webservices/library/ws-restful/ <http://www.ibm.com/developerworks/webservices/library/ws-restful/>
http://en.wikipedia.org/wiki/Representational_state_transfer <http://en.wikipedia.org/wiki/Representational_state_transfer>
(here PUT is used for replacing resources like you state it, but POST is only used for adding something. It is not mentioned how to change one aspect of a resource)
http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html <http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html>
Also kind of supports both views...
My feeling is that it is nowhere clearly written which operation to use for changing one aspect of a resource...
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).
This property of UpdateSubscription is exactly what understand under idempotency: If you apply the same operation n times in a row, the result will be the same as when applying the operation only once. And the usage of the verb PUT gives a hint that subscription updates are in fact idempotent, because PUT is required to be idempotent (while POST does not need to be in general).
Best
Tobias
From: Farkas, Lorant (NSN - HU/Budapest) [mailto:lorant.farkas at nsn.com <mailto:lorant.farkas at nsn.com> ]
Sent: Mittwoch, 8. Februar 2012 13:22
To: Tobias Jacobs; Bisztray, Denes (NSN - HU/Budapest); fiware-ngsi at lists.fi-ware.eu <mailto:fiware-ngsi at lists.fi-ware.eu>
Subject: RE: [Fiware-ngsi] proposed expansion of NGSI-10
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> [mailto:fiware-ngsi-bounces at lists.fi-ware.eu] <mailto:[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 <mailto: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> [mailto: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 <mailto: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/20120229/3122a019/attachment.html>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy