|
|
Post by garyliu on May 14, 2020 6:16:58 GMT
In Spec DataModel > Properties
If an implementation supports a property, it shall always provide a value for that property. If a
value is unknown, then the value of null is an acceptable value if supported by the schema
definition.
the question is:
If there is a property we support to PATCH and the value are unknown for some reason but it is not nullable in schema,
what value we can provide in GET method?
|
|
|
|
Post by jautor on May 14, 2020 21:12:26 GMT
the question is: If there is a property we support to PATCH and the value are unknown for some reason but it is not nullable in schema, what value we can provide in GET method?
This has come up before, regarding values set by a user, that don't have a "meaningful" value until a user sets them. `AssetTag` is a good example. In general, we would say that should be returned as an empty string - since the value is known by the Service (this isn't an error condition), it's just not set to anything...
We think the empty string is a better choice than null, regardless, and is better than any attempt to create standard placeholder text as that's unlikely to have interoperability (and would also set a developer trap if a client doesn't know that "N/A" is a special term...)
Now, that's an answer for string-based properties... If you have a case that involves a number or boolean, we'd like to know about that...
Jeff
|
|
|
|
Post by garyliu on May 27, 2020 7:09:29 GMT
We meet this issue with "BitRate" in SerialInterface for it is an enum property and it is not nullable.
Not only enum property, number and boolean value may also encounter this problem.
|
|
|
|
Post by jautor on May 27, 2020 15:11:29 GMT
We meet this issue with "BitRate" in SerialInterface for it is an enum property and it is not nullable. Not only enum property, number and boolean value may also encounter this problem. We've done some clarification in the next release of the Specification which may help you here... Is the "BitRate" not known because of an error condition (a temporary condition), or do specific instances of the serial port not have the functionality (but other instances do)? If you know the BitRate for Serial port #1, but don't support / won't be able to determine for Serial port #2, you would simply not return the property for Serial port #2. The clarification in the specification is about "implementation supports" - your code supports it, but not for *all* instances of the resource... Jeff |
|
