Allowing PATCHing of deployments obscures functionality required by API design #74

Problem description
The API design requirement is to allow the API consumer (Application Provider) to add or remove specific edge cloud zones or Kubernetes clusters. Implementing this via PATCHing obscures this feature requirement by treating it as a database entry update. This can cause:

• Ambiguous behavior, as it is not at all clear what happens when there is a conflict between the requested edgeCloudZones and kubernetesClusterRefs. The need to include a note that patching these fields results in their replacement rather than merging also suggests that use of PATCH is not considered intuitive.
• Functionality creep, as the PATCH operation allows updating of the appDeploymentName for no good reason other than PATCH supports this, and not because it is a requirement of the API design

Expected behavior
Where the design only requires a few operations to be permitted on existing deployments, these should be explicitly defined. e.g.:
POST /deployments/{appDeploymentId}/addEdgeCloudZone
POST /deployments/{appDeploymentId}/removeEdgeCloudZone
POST /deployments/{appDeploymentId}/addKubernetesCluster
POST /deployments/{appDeploymentId}/removeKubernetesCluster

This is unambiguous, intuitive, and avoids API functionality creep

Alternative solution
None proposed

Additional context
None