Combining EDS API with AED API

[javierlozallu]

Problem description
In EDS API GET /application-endpoints (at first glance and because of the name, it might overlap with AED API) and GET /mecplatforms (at first glance it might overlap with SED API or GET /edge-cloud-zones of EAM API).

GET /application-endpoints ESD API vs GET /app-endpoints AED API:

GET /application-endpoints ESD API: Returns a list of optimal Application Endpoints that client devices can connect to. You can search based on Application Profile, Region, Suscriber Density or UEIdentity.

This method is very interesting and covers part of intent 21, which is outside the scope of the MVP proposal, but was considered for the improvement phase.

Expected behavior

GET /app-endpoints AED API: Returns the closest endpoint of the App Instance for an specific UE. Based on UEIdentity and AppID
This functionality can be merged to improve Application Endpoint Discovery capability, allowing endpoint discovery based on App Profile, Region, Subscriber Density, UEIdentity and AppId.

[JoseMConde]

Hi @maheshc01, this is one of the issues that we discussed on the last meeting, as you can see the idea is to reuse the existing yaml(API), and add the funcionality of EDS to AED. Do you think is possible??
I think we can add this new funcionalities in AED adding the new funcionalities to the AED, create a PR and review the code and discuss in this PR about it,doing this we avoid to create a new API.

[maheshc01]

yes. I believe we can combine EDS in AED. it would increase the scope of AED. will discuss the updated yaml on the call and then create a PR.

[maheshc01]

have created a new branch(https://github.com/camaraproject/EdgeCloud/tree/Edge-Discovery-Service-API) and created a edge discovery service API yaml combining the discovery API available in AED and EAM. Also added a new discovery API for /regions.
As this consolidated discovery specific API yaml has API related to both edge cloud zone and application end points, i have used a generic name or edge discovery service. We can discuss on the call and get feedback from the team on how we want to handle the naming of the API.