@NoelWirzius I don't have permissions to add you as a reviewer.

Is the proposal that we have separate APIs (i.e. separate basePaths) per use case? So if connectivity status was re-introduced, that would be a new API with its own YAML definition?

Is the proposal that we have separate APIs (i.e. separate basePaths) per use case? So if connectivity status was re-introduced, that would be a new API with its own YAML definition?

Hello @eric-murray. Yes, the proposal is to have a portfolio of Device Status APIs. So we can call this API " Device Roaming Status" (which is the only use case that we currently have) and whenever we receive new requirements related to Device Connectivity Status we discuss them again and categorize them (if they’re not related to roaming) as new APIs with their own YAML files with dedicated endpoints.
The users might not be interested in all use cases that can be grouped in a big API and if we gather different kind of status/connectivity in a single API they might be forced to implement the API partially.
Does it work for you?

@monamok
Thanks. There are advantages and disadvantages of both approaches. I just wanted to be sure I understood what was being proposed. I think I would prefer a common basePath for anything that was considered to be a "device status", even if each path (i.e. use case) was published in a separate YAML file. I'll discuss internally.

Another question is that PR #21 is also proposing changes to the API definition. Either could be merged at the moment, but after the first is merged, the other will need to be re-based. Is it agreed which should be merged first?

I'll discuss internally.
@eric-murray, of course. Please let us know.

@NoelWirzius can we please have also your feedback about this?

Another question is that PR #21 is also proposing changes to the API definition. Either could be merged at the moment, but after the first is merged, the other will need to be re-based. Is it agreed which should be merged first?

I already mentioned this point in the issue #22 that I opened for this PR. If PR #21 get merged before this one, I'll update my branch with the approved changes so there's no conflict. The only thing we should decide is if we keep the version or should we update it too?

@monamok
I discussed with our developers, and they much prefer to have separate basepaths for different API definitions (i.e. different YAML files). So I'm happy to tie the basepath to the use case (i.e. /device-roaming-status). though do wonder if we should keep the path itself as status rather than also changing that to roaming.

I'm also awaiting feedback from @NoelWirzius on the order in which PRs should be treated before approving this one.

@eric-murray @monamok

we checked the different pro and cons and the cons are really big in our views. So the maintenance of the APIs will get really complex when we build for everything an own API - then we need to do changes to each API for example changing the naming or adding a new function like "list of devices"

but there are also pros of course

Our suggestion is:

• stay at one YAML and adding different Endpoints for each API

Example for Roaming, Connectivity and subscription:

server/devicestatus/v1/roaming
server/devicestatus/v1/connectivity
server/devicestatus/v1/subscriptions

is this sth we can go as a compromise?

@NoelWirzius
I'm equally happy to stay with a single YAML and common basepath. My comment was that, if we split the YAML into multiple separate files (one per status), then our developers would much prefer to have each separate YAML have a different basepath.

But if the decision is to have a single common YAML, then the basepath also needs to be common. There is no problem there.

@eric-murray fully agree with you! the same feedback I also got. If we split -> then different YAMLs - but we would prefer a single common YAML with a common basepath and just different endpoints for each "Feature"

I'm also in favor of a common YAML in order to be consistent with other API with several 'sub' function as we have this pattern in number verification API and SIM Swap API. The YAML covers the 'family' and we have several endpoints.

We have distinct YAML for Carrier billing/SIM SWAP/Number Verification when we have distinct flavor of the requirement (MC vs specific, oma vs specific) but same functions are covered in each YAML.

Thank you @eric-murray @NoelWirzius @bigludo7 for your feedback. Sorry I was trying to resolve the conflicts and I accidentally closed the PR. I'm not sure if someone from the code owners can reopen it or should I open a new PR?
I aligned the YAML file with your comments and I already pushed it to my repo in order to have a dedicated endpoint for roaming as @NoelWirzius suggested with a common base path for future usecases.

I'm not sure if someone from the code owners can reopen it or should I open a new PR?

I was able myself to reopen it :)
Could you please take a look and see if it's ok now.

P.D. If we rename the base path as you suggested to have a /connectivity endpoint in the future, we should rename the YAML file before merging it. But for the moment I kept it with the same name so we can see the GIT comparison and to find the changes easier.

Hi Team , if we will go with single YAML file for all related cases (device status) then how the basepath will be defined to create proxy. It would be challenging to have different proxy for individual endpoint (Roaming, Connectivity etc) and with single porxy, it will make our job more tough to manage Spike, authentication/Authorisation and other security policies for specific requirement.

I'm approving this because it keeps open the question of whether additional statuses (such as connectivity) should be in the same or a separate YAML. When an additional status is proposed, that issue can be addressed then.

@MarkusKuemmerle could you please add again @NoelWirzius as a reviewer. I think he was removed automatically when the PR was reopened. Thanks.