Swagger definition for Get device location

camaraproject / DeviceLocation

Repository to describe, develop, document and test the DeviceLocation API family

Apache License 2.0

21 stars 32 forks source link

Swagger definition for Get device location #55

Closed bigludo7 closed 1 year ago

bigludo7 commented 1 year ago

First stab for API definition for retrieving a device location. There are points to be commented in this PR and discussed in team meeting:

I've not yet provided any documentation - will do once we agreed on the interface directly in the OAS.
Use of device identifiers as defined in latest QoD version (phoneNumber an not MSISDN) - this introduce a gap with the check api.
Definition of a specific scope distinct from the check operation
In the response only lat/log & accuracy are provided. I opted to provided straightforward information and not use area schema (with oneOf) --> could be challenged.
We need some update on the other api - for example the little for the existing api should be check device location API instead of device location API.
etc.

bigludo7 commented 1 year ago

Discussion in Commonalities --> https://github.com/camaraproject/WorkingGroups/issues/212

bigludo7 commented 1 year ago

@JoachimDahlgren @jlurien @rartych

changed operation to POST
aligned with QoD device identifier structure.

I suggest to tackle check-device device identifier structure alignment in another PR once this one merged. Then we will create 2 other PR to add subscription management.

bigludo7 commented 1 year ago

Hello @jlurien @akoshunyadi @JoachimDahlgren @rartych Kind reminder I've applied all required changes 2 weeks ago. Looking for your review as we planned to release this API in July Thanks

bigludo7 commented 1 year ago

@jlurien : updated the OAS - looking for your feedback in particular for the integration of the inheritance model for the area.

bigludo7 commented 1 year ago

@jlurien Everything look resolved from my perspective - Ok for you? Waiting for your approval to merge it

jlurien commented 1 year ago

@jlurien Everything look resolved from my perspective - Ok for you? Waiting for your approval to merge it

Let's discuss it tomorrow. Merging it now may impact the releasing process for v0.2. We may prefer to wait until v0.2 for location-verification is released and then merge the first PRs for the new APIs in the family.

bigludo7 commented 1 year ago

@jlurien Thanks for the comment. Yes this a good point to have consistency between the server name path & the scope.

locationseems to me a bit short and I will probably prefer location-retrieval as in the other API we have location-verification. I will change the server name but open to reverse this if you & the team strongly prefer using only location.

jlurien commented 1 year ago

@jlurien Thanks for the comment. Yes this a good point to have consistency between the server name path & the scope.

locationseems to me a bit short and I will probably prefer location-retrieval as in the other API we have location-verification. I will change the server name but open to reverse this if you & the team strongly prefer using only location.

To me is OK. Indeed, any time I have to mention this API internally I have to clarify that is location (retrieval), as location is applied to all the family of APIs in this WG

bigludo7 commented 1 year ago

@jlurien Agreed. I will wait till Monday and then proceed (and work on the documentation part) As it is still in wip we can still accommodate comment after - if any.