Edge discovery APIs enhancements

[kohlian18]

What type of PR is this?

• enhancement/feature
• cleanup
• Documentation

What this PR does / why we need it:

This segregates and simplifies edge cloud zone and application endpoint discovery APIs:

• GET edge cloud regions API to fetch edge cloud region id and name required for discovery APIs.
• POST method containing standardised device information schema along with application profile id for edge cloud zone discovery.
• POST method along with device information with application endpoint ids and edge cloud regions for application endpoint discovery.
• added information for access and authorisation token

[gunjald]

I suppose this intent "discover optimal edge cloud zones for deployed applications" is valid for the end users which would connect with the edge applications instances. In that case we need to possibly indicate the different type of users who may consume these APIs.

[kohlian18]

Resolved. Added two scenarios for api usage: Edge Cloud Zone Discovery and Application Endpoint Discovery

[gunjald]

It is bit confusing when it says the users can use this API to enhance connectivity and performance by selecting suitable edge cloud zone and application endpoints. In my view the app providers may need to use this API to deploy applications while the end users may use it just to discover application endpoints to connect with.
So in terms of the usage it would be good to describe the scenario where the given intents are to be used by the intended users as per the goals of the API. Thoughts?

[kohlian18]

resolved

[gunjald]

As per the use cases described here it seems to propose two category of users that is app developers and client applications. If this is correct how does API assumes the authorization for these users interactions with API?

[JoseMConde]

Should we update the name to Optimal Edge Discovery as we agreed in the last meeting??

[kohlian18]

Should we update the name to Optimal Edge Discovery as we agreed in the last meeting??

Sure, i will update it and push the changes.

[JoseMConde]

Trying to see the API in a more generic view, I have some concerns:

1. The first point is that I still thinking that the methods should be Get not Post. The approach is almost the same than the Get/Edcloudzones that we have in EAM and also in AED, we can have a Get with some parameters inside the request body and some of them could be required and some of them not.
2. Another point is that Post/Edge-cloud-zones, doesn't have the same approach than Get/Edgecloudzones that we actually have in EAM. I think is interesting that the developer could filter by status. Also the ApplicationProfileId is a mandatory parameter, but maybe someone doesn't use Application Endpoint Registration and doesn't have this parameter or they use it for some Applications and for others they don't.
3. Analizing the behaviour of POST/app-endpoints in this API and the behaviour of Application Endpoint Discovery, could be almost the same, the only thing taht is different is that we use AppId to know wich is the Application that we need the endpoint and this API uses ApplicationEndpointsId, am I wright or I am missing something??