application end point registration API yaml #321
Conversation
maheshc01
requested review from
gunjald,
Kevsy,
crissancas,
FabrizioMoggio,
nicolacdnll,
gainsley and
JoseMConde
as code owners
🦙 MegaLinter status: ✅ SUCCESS
See detailed report in MegaLinter reports MegaLinter is graciously provided by |
| url: https://www.apache.org/licenses/LICENSE-2.0.html | ||
| description: | | ||
| Application endpoint registration allows application developers to | ||
| register one or more Application Endpoints, and retrieve, update,and |
There was a problem hiding this comment.
Should we have a definition for "Application Endpoints" to make it more explicit?
There was a problem hiding this comment.
I also think that these Application Endpoints are not generic and they corresponds to the application instances running on edge cloud zones in probably distributed manner. So should we qualify the Application Endpoints in some way to indicate developers about the expectations from these endpoints i.e. edge instances?
| description: | | ||
| Application endpoint registration allows application developers to | ||
| register one or more Application Endpoints, and retrieve, update,and | ||
| delete those egistrations. |
There was a problem hiding this comment.
I suppose egistrations is should be "registrations"
| This information can we used for various usecases like optimal end | ||
| point discovery to help end users connect to the most most optimal | ||
| instance of the application. Addtionally the information can be used |
There was a problem hiding this comment.
I feel that if can refer or qualify applications as "edge applications" then it will make it more related to edge deployments while using generically may imply any deployment including clouds. Just a thought.
| delete those egistrations. | ||
| This information can we used for various usecases like optimal end | ||
| point discovery to help end users connect to the most most optimal |
There was a problem hiding this comment.
"most most optimal" should be changed to "most optimal"
| items: | ||
| $ref: "#/components/schemas/ApplicationInstance" | ||
| responses: | ||
| "200": |
There was a problem hiding this comment.
We should also consider the additional status codes which could be valid for the POST requests in alignment with other APIs and consistency.
| paths: | ||
| /application-endpoints: | ||
| post: | ||
| operationId: register-application-endpoints |
There was a problem hiding this comment.
For the POST method should we also include "x-correlator" header as done with other APIs.?
| edgeCloudRegionId: | ||
| $ref: "#/components/schemas/EdgeCloudRegionName" | ||
| ResourcesapplicationEndpoint: | ||
| type: object |
There was a problem hiding this comment.
Should we assume that an application can expose only one endpoint or there could be more than one for different purposes? If there can be more than one which only application provider knows then this parameter should allow the multiplicity by having it as an array of objects. Also in that case with each endpoint there should be a discriminator field to allow client applications to know the purpose of a specific endpoint.
There was a problem hiding this comment.
Although the top level object is an array but then if application has multiple endpoints some of the information will be repeated that many times as they will be common to an application.
…ts-functionality-to-be-a-new-api EAR: Fixing Typo
|
@urvika-v tagging Urvika for review and updates |
What type of PR is this?
This PR is to review and update application endpoint registration API yaml.
Add one of the following kinds:
What this PR does / why we need it:
Initial commit of the yaml to provide ability to register application endpoints.
Which issue(s) this PR fixes:
issue #286
Fixes #
Special notes for reviewers:
This is only the initial commit and additional updates are required related to documentation, error codes etc to ensure it meets the CAMARA guidelines.
Changelog input
Additional documentation
This section can be blank.