Separate endpoint yamls proposal for direct API#152
Conversation
Separate endpoint yaml for reachability & roaming.
This comment was marked as outdated.
This comment was marked as outdated.
Fix mega-linter
Fixed megalinter
bigludo7
left a comment
There was a problem hiding this comment.
Fixed mega-Linter
| - name: Device reachability status | ||
| description: Operations to get the current reachability status of a device | ||
| paths: | ||
| /retrieve-reachability-status: |
There was a problem hiding this comment.
@bigludo7 I see that for example in location-retrieval the WG opted for "/retrieve", in location-verification for "/verify", etc
If we have reachability-retrieval maybe we can go with "/retrieve" too? wdyt
There was a problem hiding this comment.
Hello @fernandopradocabrillo
Yes make sense !
For the API name, today is reachability-retrieval - do you think we need to shift to reachability-status and then have an endpoint /retrieve - This is perhaps more straighforward?
Same will happen for roaming.
There was a problem hiding this comment.
sounds good to me, it looks clearer
There was a problem hiding this comment.
/retrieve would be good.
API name: I would prefer device-reachability-status, which contains the context 'device' for the case other reachability status API will come later.
|
@bigludo7 @akoshunyadi |
|
@maxl2287 we can do the 2 subscription APIs in a 2nd PR to the splitting issue |
Both work for me |
|
2nd PR is #161 for splitting |
| - name: Device reachability status | ||
| description: Operations to get the current reachability status of a device | ||
| paths: | ||
| /retrieve-reachability-status: |
There was a problem hiding this comment.
/retrieve would be good.
API name: I would prefer device-reachability-status, which contains the context 'device' for the case other reachability status API will come later.
| title: Device Reachability Status Retrieval | ||
| description: | | ||
| This API provides the customer with the ability to query device: | ||
| - Reachability status |
There was a problem hiding this comment.
This list suggests that other infos might come later, but this is a specialized API.
| "403": | ||
| $ref: "#/components/responses/ReachabilityPermissionDenied403" | ||
| "404": | ||
| $ref: "#/components/responses/ReachabilityNotFound404" |
There was a problem hiding this comment.
I can see that we have the generic NOT_FOUND in addition to the DeviceIdentifierNotFound.
In which scenario does the API return an standard NOT_FOUND?
There was a problem hiding this comment.
I agree with @fernandopradocabrillo
Maybe later for such a case we should more go the way of having a reachability Status UNKNOWN with HTTP - 200 than a HTTP-404 for Reachability not found.
see #148
@bigludo7 wdyt?
There was a problem hiding this comment.
@maxl2287 @fernandopradocabrillo I can remove the NOT_FOUND. No problem.
BTW we're still waiting outcomes for #148 which is a fair point. I will comment there.
| ReachabilityPermissionDenied403: | ||
| description: | | ||
| Client does not have sufficient permission. | ||
| In addition to regular scenario of `PERMISSION_DENIED`, other scenarios may exist: | ||
| - Phone number cannot be deducted from access token context.(`{"code": "NUMBER_VERIFICATION.INVALID_TOKEN_CONTEXT","message": "Phone number cannot be deducted from access token context"}`) |
There was a problem hiding this comment.
@bigludo7, is this a valid 403 error?
Currently, we are not extracting or verifying a phone number from the access token. This situation seems more related to Number Verification rather than Device Status.
Do you agree?
There was a problem hiding this comment.
Good question :)
For me this API could be sent from the device itself in frontend flow and in this case we got the phoneNumber from the network (see ICM proposal here). I need to update the yaml to not have device mandatory anymore.
So I think we should keep this error to manage this case but of course shifting prefix from NUMBER_VERIFICATION to DEVICE_REACHEABILTY_STATUS.
WDYT?
There was a problem hiding this comment.
If we make the device not mandatory then, for me, it makes sense to keep the invalid token context error.
There was a problem hiding this comment.
Yes @fernandopradocabrillo - This is my preferred option.
There was a problem hiding this comment.
If we offer this possibility over the access token, then we should extend the documentation. Otherwise the user has no idea when he needs to add the device.
btw. the example still contains number-verification
There was a problem hiding this comment.
@akoshunyadi Thanks - Fixed!
I've applied what we have in commonalities here
PR233 will change this but I will prefer we look for merge this one and craft new PR for additional alignement because then it is complicated to maintain.
There was a problem hiding this comment.
Applied same fix for device-roaming-status api
Changed endpoint to /retrieve Took suggestion on documentation Device is not anymore mandatory Add 422 for Network issue - Unable to provide reachability status I think we're not on same page on the api name.
There was a problem hiding this comment.
Applied updates on device-reachability-status yaml:
- Changed endpoint name to
/retrieve - Took suggestion on documentation from @akoshunyadi
- Device is not anymore mandatory
- Add 422 for Network issue - Unable to provide reachability status
About the api name.
@akoshunyadi propose device-reachability-status (I proposed reachability-status) but ok for me to move forward with Akos proposal - any issue from the team for the name.
Note: I will apply same on device-roaming-status API
Update scope name
Aligned with device-reachability-status update.
|
Aligned device-roaming-status with the work done with device-reacheability-status. |
| openapi: 3.0.3 | ||
| info: | ||
| title: Device Reachability Status Retrieval | ||
| description: | |
There was a problem hiding this comment.
Add ## Authorization and authentication doc
|
Hi team I've fixed that (I hope so) + added Authorization and authentication § in the doc as suggested by @fernandopradocabrillo for both yaml. Sorry for the confusion. |
|
Where do we want to delete the old yaml? We could do it in this PR. |
|
I aggree with @akoshunyadi. |
|
@akoshunyadi @maxl2287 added delete the old file in this PR |
| Client does not have sufficient permission. | ||
| In addition to regular scenario of `PERMISSION_DENIED`, other scenarios may exist: | ||
| - Phone number cannot be deducted from access token context.(`{"code": "NUMBER_VERIFICATION.INVALID_TOKEN_CONTEXT","message": "Phone number cannot be deducted from access token context"}`) | ||
| headers: |
There was a problem hiding this comment.
Here it's a remaining of NUMBER_VERIFICATION, should be replaced
There was a problem hiding this comment.
@bigludo7 could you please do this update, so we can approve and merge this PR? Thanks!
Fixed line 343 - wrong description.
|
@sachinvodafone @fernandopradocabrillo may I ask you to review this one for blocking point as we target to merge this one soon. Thanks |
|
@akoshunyadi Due to git hub conflict issue I reinserted the 'old' device-status.yaml file and will remove it an a separate PR. |
| reachabilityStatus: CONNECTED_DATA | ||
| Not-Connected: | ||
| value: | ||
| lastStatusTime: "2024-02-20T10:41:38.657Z" |
There was a problem hiding this comment.
Do we have an example where network is connected to both SMS and Data and we need to send a response accordingly like: {
"lastStatusTime": "2024-02-20T10:41:38.657Z",
"reachabilityStatus": "CONNECTED_SMS_DATA"
}
There was a problem hiding this comment.
For me no as my understanding DATA means that SMS is also available.
@sachinvodafone I will merge this PR so probably we could continue the conversation in Discussions tab as it does not impact this merging.
What type of PR is this?
Add one of the following kinds:
What this PR does / why we need it:
Separate endpoint yaml for reachability & roaming.
Which issue(s) this PR fixes:
Fixes #125
issue for Device error identifier to be added.
Special notes for reviewers:
Yaml for both roaming & reachability subscription provided once new subscription model merged in Commonalities
API name & endpoint to be validated by the team
Changelog input
Additional documentation
This section can be blank.