Create connected-network-type-subscriptions.yaml #171
Conversation
Review comments added
…network-type-subscriptions.yaml correcting the file name and making it plural
…ription Merging after approval
VijayKesharwani
requested review from
eric-murray,
bigludo7,
sachinvodafone and
akoshunyadi
as code owners
|
@camaraproject/device-status_codeowners I guess this can be moved together with #158 to the newly created https://github.com/camaraproject/DeviceQualityIndicator, do you agree? |
I think the quality indicator is something different. It will need different inputs, e.g. the network type, to provide a network quality indication. |
|
It is mentioned under quality indicator "Get insights about the network status of a defined mobile device." so I am not sure if it will have some other inputs other than mobile device. |
|
@VijayKesharwani Let's keep this subscription API in sync with the non-subscription one in #158. There there was a change in the enums. As soon as we have an approval there this PR should be updated. Thanks. |
There was a problem hiding this comment.
Thanks !
In order to mix ourselves could you add in the yaml the commonalities reference.
In this case add a line btw 61 & 62 to add
x-camara-commonalities: 0.4.0
cc: @akoshunyadi
| description: | | ||
| network-type-changed - Event triggered when the connected network type of the device changes. | ||
| enum: | ||
| - org.camaraproject.connected-network-type-subscriptions.v0.network-type-changed |
There was a problem hiding this comment.
We need the subscription-ends event here and the corresponding description in info.description
Added subscription-ends event
| example: | ||
| status: 429 | ||
| code: TOO_MANY_REQUESTS | ||
| message: "Endpoint does not support as many requests per time slot" |
There was a problem hiding this comment.
It seems, message under the example is not the same as we defined in the CAMARA_common.yaml. Can we keep different description other than mentioned there or would it be in synch.
There was a problem hiding this comment.
Error messages are always examples. Implementations are anyway free to define their own error messages, irrespective of what is documented in the OAS definition. So individual sub-projects are also free to use different error message examples if it better clarifies a particular error for a particular API.
What type of PR is this?
Add one of the following kinds:
What this PR does / why we need it:
(#143)
Which issue(s) this PR fixes:
(#143)
Fixes #
Special notes for reviewers:
Changelog input
Additional documentation
This section can be blank.