Dedicated Portal Instance for CAMARA

[jordonezlucena]

• The idea would be to have a single, unified portal instance for the entire project, hosting the different APIs developed and with tools allowing for their management (source code, documentation, etc.).

• TEF has a portal with API management capabilities that can be reused for CAMARA. The idea is to make people aware of these capabilities, and assess if CAMARA find them useful. If so, TEF could build out a dedicated portal instance for CAMARA project (tailored the initiative needs, including branding).

• The action is on partners to check the PDF uploaded (https://github.com/camaraproject/WorkingGroups/blob/main/Commonalities/documentation/Working/API%20Portal%20Capabilities.pdf), and take a 'go' / 'no-go' decision accordingly.

[jordonezlucena]

The presentation has been updated. Please, check

[T-sm]

Thank you very much for the proposal!
I find that such a portal may be crucial for further Camara's API development and support this idea.
The decision will be voted during the next Commonalities meeting.
If there is no quorum, the voting may be continued asynchronously within this issue.

P.S. In line with request #35 the presentation has been moved to https://github.com/camaraproject/WorkingGroups/blob/main/Commonalities/documentation/Working/API%20Portal%20Capabilities.pdf

[Kevsy]

Per discussion at last meeting I've added API development portal requirements. Once agreed we can make a decision on how to deliver them.

[jordonezlucena]

Hi @Kevsy: I'm not sure whether we're in position to deliver all these dev related capabilities with the solution we proposed. At least, the points captured below I'm not 100% sure we have them ready in the portal.

• API testing automation against CAMARA commonalities/API principles
• Sandbox execution of API requests against local stubs (dummy data)
  -- API consumer AuthN/AuthZ capability for executing the dummy API requests

Let me check with my colleague Rubén and come back to you.

[Kevsy]

Thanks Jose - the group can agree which requirements are mandatory, and which are optional/'nice to have'/'for the future'. There may also be other requirements I've missed.

[RubenBG7]

Hi @Kevsy. I'm trying to review the API development portal instance requirements that you published in 4 hour ago comment and i cannot get it. GIthub returns me a 404. Could you attach it again?

[Kevsy]

Sorry Ruben! I renamed the file as .md and forgot to update the link above. It is here

[RubenBG7]

Thanks @Kevsy

[RubenBG7]

in scope:

• API catalogue

  • Principal proposal

• tagged descriptions of each API

  • API could be tagged by realm, category and subscategory

• tags to include functional category and API status (alpha | beta | published)

  • API could be tagged by category and it could be tagged as DRAFT or not

• Documentation repository

  • You can upload documents and tag them by project, country or any other tag and category

• conformance testing automationm for documentation against CAMARA API documentation templates

  • Document validator or template testing is not in scope

• Client & server code generation

  • Client & server template code generator based on a swagger schema available

• API testing automation against CAMARA commonalities/API principles

  • Certification tool optional to validate services implemented responses against CAMARA swagger schemas publised in the portal catalog

• Sandbox execution of API requests against local stubs (dummy data)

  • Sandbox is deprecated due to the maintenance requirements but redoc viewer expose basic examples of all request and response bodies

• API consumer AuthN/AuthZ capability for executing the dummy API requests

  • Catalog is not modeled to make any dummy API request Authorized

• Links to operator API portals

  • Possible to include in the future

out of scope: the portal will not

• expose, invoke or proxy live API calls against operator network

  • Not designed to do that

• provide registration to operator API portals

  • Not designed to do that

[Kevsy]

API development portal requirements updated with Postman Enterprise and Stoplight.io for comparison.

[shilpa-padgaonkar]

@MarkusKuemmerle : This issue cannot be resolved in Commonalities. This involves decisions which includes handling costs and efforts and hence needs to be addressed in Steerco meeting. Removing the commonalities label after internal agreement with commonalities members and re-assigning the issue to you.

[MarkusKuemmerle]

I would keep it simple for the beginning an start with a simple table. Please sync with API Backlog group, it would be great to have only 1 table for backlog and APIs in development / production.

[MarkusKuemmerle]

See #53

[shilpa-padgaonkar]

We can accept this as a temporary solution for now.

[jordonezlucena]

@shilpa-padgaonkar: the issue was closed but the topic for discussion deviated into 'API backlog', which is far from what originally intended: "Dedicated Portal Instance for CAMARA". Would it make sense to re-open this issue again and provide an action plan towards SteerCo?

[shilpa-padgaonkar]

@jordonezlucena : Sure, you can reopen this issue with the scope to create an action plan towards Steerco. I will assign the issue to you.

[jordonezlucena]

Thanks. We are working out this internally. We'll prepare something for discussion (and potentially ballot) for upcoming SteerCo.

[jordonezlucena]

Dear all,

We have made a cost analysis on the platform, computing both CAPEX and OPEX. See costs deseeded below

Item (Category)	Concept	Cost	Details
C1 (CAPEX)	Portal instance creation	~15 K€	1 month to get the portal up and running
C2 (OPEX)	Hosting (infra)	500 € (peanuts)	Hosting in Azure 1
C3 (OPEX)	Support and maintenance	~20K€	Estimated effort = 2,5 PMs/year. 8x5 support

Executive Summary

Year	Cost	Details
Y1	35K€	C1+C2+C3
Y2, Y3, ….	20K€	C2+C3

As we are been informed that these costs will not be eligible for Linux Foundation (and we foresee it might be difficult for CAMARA partners to contribute to these costs), we have decided not to go ahead with the Portal offering.

@shilpa-padgaonkar: Following the above rationale, it is proposed to close this issue with the decision 'not to go ahead'

[shilpa-padgaonkar]

Closing the issue as suggested by @jordonezlucena