Analysis:

There are 3 Operations:

1. Discovery

2. Application Endpoints

3. Application Profile

- In my opinion an API named **Discovery** should contain only `GET` methods to discovery status/attributes for a given parameter but currently EDS API contains CRUD methods.

Impact Analyse

- 1. Discovery:
  - This operation has two methods `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.

    - `GET /app-endpoints` AED API: Returns the closest endpoint of the App Instance for an specific UE. Based on UEIdentity and AppID
    
    My conclusion is that each method has different functionality but can be merged to improve Application Endpoint Discovery capability, allowing endpoint discovery based on App Profile, Region, Subscriber Density, UEIdentity and AppId. 
    
  Note: There are some considerations to take into account if we agree on the merger.

   `GET /mecplatforms` ESD API vs `GET /edge-cloud-zones` EAM API:
    - `GET /mecplatforms` ESD API: Returns a list of optimal MEC Platforms where you can register your deployed application. You can choose to search without passing any of the inputs parameters or combination of Application Profile, Region, Subscriber or UEIdentity.

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

    - `GET /edge-cloud-zones` EAM API: Returns a list of Edge Cloud Zones and their status, ordering the results by location (region) and filtering by status (active/inactive/unknown)
    
    My conclusion is that each method has different functionality but can be merged to improve Edge Cloud Platforms(?) discovery capability, allowing developers to discover them based on Application Profile, Region, Subscriber, UEIdentity and Status.
    
  Note: There are some considerations to take into account if we agree on the merger.

- 2. Application Endpoints:
  -  This Operation allows to: Register and manage the routable Application Endpoints of your deployed applications.
  - Currently the approach is that endpoints are fully managed by the Edge Platform and Developers can ask for this information through `GET /apps/{appId}/instances` EAM API method.
  - I don't found any intent related to this capability but I think is very interesting to have it because of two reasons:
    - If the developer deploys the application on a hyperscaler
    - If the developer wants to use their own domains, this relates to a comment in #271 to have a new API: `Bring Your Own DNS/Endpoint/Whatever` which allows the developer to use and manage third party domains (other than the Edge platform). So this contribution will serve as a basis for this.
    - A different approach I see here is to add it in the onboarding process within the EAM API, but I don't quite like it. 
    
- 3. Application Profiles:
  - This Operation allows to: Create and manage profiles that describe the application requirements of your MEC applications, such as the required connection bandwidth and maximum latency.
  - In my opinion this Operation is very interesting and covers part of intent 5, which is outside the scope of the MVP proposal but was considered for the enhancement phase. But it should be placed in the onboarding process within the Edge Application Management API.

Note: I have not added the impact to the SED API because, as far as I understand, the approaches are different, but feel free to add it to the analysis if needed.

0.11.0-alpha.1 is under development and expected to be available by 12th July. Progress so far:

- incorporated: Commonalities 203,214,233, EdgeCloud 119 (adding public port)

- checked (no change needed): Commonalities 152,170,177,189

- underway: update the errors to align with Commonalities 0.4rc.1 common.yaml