Define mandatory end points URL in each project

[psidana1983]

Hi Team ,

As per the CAMARA documentation each project as multiple resources or end point URLs exposed. As a client I am not sure what all end points are mandatory to expose to be CAMARA compliant . So can i suggest to update the YAML file and define the mandatory end point URLs , with test cases . This can help the clients to decide what to implement .

Ex: Device Status API has multiple end point URLs but I am not what all ends points should i expose to be CAMARA compliant ?

Regards Prashant Sidana

[hdamker]

Hi Prashant, please see also my answer at your previous question in https://github.com/camaraproject/DeviceStatus/discussions/72

I don't get what you mean with "mandatory" endpoints ... all endpoints defined within an API version need to be implemented by a provider implementation, at least be answered with appropriate return codes and error messages if you don't have implemented the functionality behind it for some reason.

But I don't get your sentence

This can help the clients to decide what to implement

Are you asking here about provider implementation (a network providing the service defined by the API) or about API clients/consumers? The latter one will always decide themselves which endpoints they will need for their use cases. If you are talking about a provider implementation - may I ask for which kind of network you are implementing the API?

Thanks for your proposal to provide test cases for at least the most important functionality of the APIs ... that's indeed something which we will need to add to get more mature.

[eric-murray]

@psidana1983 This issue should be raised in Commonalities. Unfortunately, I don't have the necessary rights to transfer directly, so please close this and open a new issue in the Commonalities sub-project.

[hdamker]

@eric-murray @psidana1983 Will transfer the issue.

[bigludo7]

I'm wondering if we should not go more in detail on conformance for each API?

I have few examples in mind to illustrate this:

• In simswap API we have 2 resources (check sim swap date and provide last sim swap date) - are we fine if an implementer only motorize one of the 2 and throw 5xx for this other ? or do we want to mandate the check and be ok with a 5xx for the provide ?
• In device location, we check a mobile location on a geo zone - do we want to mandate that the circle must provided in all implementation while the polygon or the postal code use are optional?
• In device status is it fine if a 5xx is send for the synchronous request (for POST Roaming) and only subscription is provided ?
• in Carrier billing payment is is fine if an implementation provides only one step payment feature and not the 2-steps one (or reversely) ? is it fine if an implementation only provide payment status & date as search criteria for the GET / and not all other attributes?
• ...

Probably we need at the WG level to provide some kind of 'conformance profile' (perhaps is it the test cases) and sync with our friends of Open Gateway product stream when they are the initiator of the request?

[psidana1983]

Hi Team , So the conclusion is to implement all the end points or at least be answered with appropriate return codes and error messages if for some reason one cannot implement it .

I suggest for such cases , let us defined the error codes and messages in the documentation itself so that all the implementers will return similar information back to the clients.

Regards Prashant Sidana

[chrishowell]

I think it would be better to treat endpoints like we're treating families now; so it wouldn't be required for a network to provide e.g. sim-swap:retrieve, but they could implement sim-swap:check-date without having to implement a noop/error endpoint. This would mean splitting these specs into distinct files, but I don't think that's a problem is it?

[tanjadegroot]

Proposal from the RM meeting (https://wiki.camaraproject.org/display/CAM/2024-05-14+Release+WG+Minutes) is to handle move this item to the Governance project to discuss on how and where best to handle this aspect. @hdamker to please transfer the issue.

[hdamker]

I will close this historic issue and propose to continue the discussion within the well structured issue https://github.com/camaraproject/Commonalities/issues/246