-
Notifications
You must be signed in to change notification settings - Fork 63
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Clarifying how readmultipleproperties work #848
Comments
request data = response payload |
But request payload means body for the HTTP request which would then conflict with the default assumption of using the GET method which is recommended to not have a body. Maybe it is even better to leave it not defined since it would differ for protocols? |
well it is not the best practice, however, http spec does not forbid using body on a GET https://tools.ietf.org/html/rfc7231#section-4.3.1
I would expect that there will be separate topic defined where you can provide the desired properties. |
Ok, in this case, I would propose to close this issue and keep it not exactly specified since it would depend on protocols and the binding templates document can explain how it would work for different protocols. |
In 2020-02-28 TD call, it was suggested to keep this issue open till we have a consensus on how to properly implement this feature. |
Do have enumerable concrete use cases for the feature?, or just filling a theoretical gap? Is there guaranteed semantics, like is Apps would not lose much since they still have the |
One way to do
There was a mention in the call of 28/2 that Mozilla had this implemented but I couldn't find it in their documentation. @benfrancis do you have an opinion? |
There is also a problem if Thing wants the Consumer to provide a list of property names in uriVariables. For example, the request needed is the following:
which returns the values of property1 and property2. I would expect that the Thing level form would be something like: "forms": [{
"op": "readmultipleproperties",
"href": "http://example.com/{?props}",
"contentType": "application/json",
"htv:methodName": "GET"
}] How can we specify that the values of "uriVariables": {
"props": {
"type": "array",
"items":{
"type":"string",
"@type":"properties"//this is not the correct one but something similar
}
}
} |
Yet another aspect to think about: {
// ...
"forms":[
{
"href":"http://example.org/myfavouriteproperties",
"op":"readmultipleproperties",
"contentType":"application/json",
"htv:methodName":"GET",
"description":"returns property 1 and 2"
}
]
// ...
} Also, this would raise an issue on how the Consumer would know that only property 1 and 2 would be returned. |
At the moment the |
But I don't consider this an important use case, as said before properties in interest could be collected in an object and exposed as a single Property. We could apply the narrow waist here. In most GObject use cases as well, getting all properties was far more used than just getting some of them. Do we have documented use cases for it? |
Should this array contain the name of properties whose values would be returned? |
Of course :). It should be an array of strings. |
@egekorkan wrote:
Sorry I missed this question. Mozilla's implementation has the equivalent of Mozilla's Web Thing Description provides a
The Web Thing REST API specification says that a
There is no equivalent to @zolkis wrote:
+1 |
IF we want to state the list of properties returned in a |
It's quite clear the list of properties should be provided as parameters by the app, and we need the infrastructure for that. However, I am not convinced the whole use case is needed, or useful at all. Some real examples would be needed for one app that wants to get just some properties in a single request while another app wanting a different set, but neither one wanting the full set of properties (and why not). |
I do agree that we need a use case here. The only thing that it comes to my mind is that one client might want to really optimize the network usage, reading only one subset of properties instead of all of them. It is really a corner case...
Agree |
To summarize, the current formulation in the TD spec needs to be more specific:
It should define
|
I think When there are 100 properties, but if the Consumer only needs 50 among them, it may be useful if the Consumer can specify the filter in the data of the request (i.e. request data). How this data in the ' readmultipleproperties` operation is encoded should be up to the protocol binding. I think the data schema is explained in the following clause, and there is not a way to override it.
At the time, the proposers argued this is needed for describing OPC-UA. |
If this should be handled by the protocol, why is there the clause that prescribes that the needed property names should be an Array? This makes it somewhat impossible to use uriVariables, which would be the only way to do this in HTTP without breaking best practices. Additionally, how would I specify the Regarding:
Then the proposers should have showed a TD or an implementation, now we have no record of how this feature was even needed in the first place. My recommendation would be to simply remove this clause with the Array and at the same time introduce uriVariables to the Thing level, see comment above. Furthermore, this "feature" somehow got into the official specification even though there aren't two implementations supporting it on the Thing side. Not sure what are the 2 implementations shown in the implementation report but if I search for |
In 2020-06-12 telecon, it was suggested to discuss in F2F meeting whether there is an use case for |
In the virtual F2F TD session on 2020-06-26 (see minutes), the WG noted that readallproperties is sufficient, and one possibility is to remove readmultipleproperties in the coming version. In the meantime, it was suggested to investigate more for now even though it seems removing it makes more sense. |
Just to add one thought to this issue: Maybe you could simply specify the list of properties in an array within the For example: "forms": [{
"op": "readmultipleproperties",
"href": "http://example.com/multipleproperties",
"properties": ["status", "brightness"],
"contentType": "application/json",
"htv:methodName": "GET"
}] I think one condition for using this approach would be that that data has to be returned as an object as described by @benfrancis, like so: {
"status": "on",
"brightness": 254
} I think one possible use case for this approach could be having a Thing that consists of multiple parts. Using multiple |
When it's the Thing that exposes a multiple-part structure, its TD can define properties as objects (of properties) as well. Even more, one can define separate Things that just re-structure the resources available on that platform, in order to present different Thing-defined views. I think the purpose of readmultipleproperties ops would be a generic mechanism to "select a view" over the Thing, where the view is defined by the apps, not by the Thing. One question (from IoT side) is how much support would this have from the various underlying protocols, and what complexity would it introduce to a WoT runtime / bindings to implement an explicit mapping when an implicit support is not there. But I sympathize more with the apps side, i.e. "make IoT accessible for the Web platform" - which in principle requires simplicity of interactions, which is why the solution outlined by @benfrancis seems elegant. If we start from the apps side API, the approach outlined by @takuki makes sense: a read ops could have filters, where
And why not, the result can be specified as an object (property bag). However, because of the significant complexity overhead, the latter approach needs to be backed by a strong set of consistent use cases. I don't see the multiple-read feature as vital to the TD spec, since
|
I do not understand the comments of @zolkis exactly. Regarding what @JKRhb wrote, I think it addresses my comment:
which is in case this operation is for a static set of properties. I think this is also a valid option. There should be a way to make this such that the Consumer chooses the properties it wants. |
The TD spec is not clear on how to implement
readmultipleproperties
from the Consumer side. The corresponding paragraph is:The words
request data
exist only here in the document which is not clear where this array should be in the request. This op value raises another concern since in protocols like HTTP and CoAP it is not a good practice to send a body/payload with a GET request if this is what is hoped for. In MQTT it would not be possible at all as far as I know.I am guessing that
request data
was written explicitly and it would be the job of protocol bindings document to explain how to incorporate it?The text was updated successfully, but these errors were encountered: