The original definition of the API is designed to allow the consumer of the API This proposal is intended to allow the user of the /appinstances resource to request the deployment of the same applicationin different zones, with one single call.

This proposal seem to modify that behaviour by only allowing the deployment of an application in one zone per single request.

I think the original behaviour should stull be possible to simplify the user of the API, therefore I identify the following potential options to this

1. Create a new resource, different than /appinstances to manage a single deployment per request
2. Leaving the original definition of /appinstances but modify the response so that it provides the status of each of the deployments that are triggered upon the request (zone and status of execution of request)

I have the same concern than @LuisVTazon commented, the idea is to make things easy to the use of the API, with this change we are obligating to the user to deploy these applications one by one per each zone.

I'm not sure it would necessarily be easier. For example, if you are deploying through a web UI, the user will probably check a bunch of check boxes for which zones to deploy to, and then hit a deploy button. Whether the UI code runs one API call or many, the user doesn't actually know. In fact, individual calls may be better, in case some finish earlier than others, the user gets feedback sooner, rather than having to wait until all AppInstance requests are processed.

How are you imagining these APIs will be used?

Additionally, the DELETE API is for a single instance, so anyway DELETE must be managed one-by-one. It seems inconsistent that the API allows me to create many at once, but only delete one at a time. Why is this optimization necessary for create, but not for delete?

If we have a multi-zone API call:

• what is the overall response status code if some AppInsts are accepted (202), some fail (400), and some have conflicts (409) or other statuses?
• if a target zone already has an instance of the Application, is the intent that we create another instance, or is this a conflict (409), or do we accept and return the ID of the already existing AppInst?

Hi @gainsley ,
As far as I know, the idea of Camara APIs is not be exposed by web UI, the idea is that APIs should be call directly by the developer without web UI.
In my view, is different when we talk about delete or deploy, I mean, if you by mistake deploy several Instances instead of just one, this doens´t impact in the final user, but if you delete several Instances by mistake, this could impact in the final user, for this reason, we didin't allow the developer to delete several Instances in one call.
About your questions, you are totally wright, we need to improve this.
For the first question, I think the response could be an array of responses, something like this:
One response per AppInsts.

• 202, Application instantation accepted.
• 202, Application instantation accepted.
• 202, Application instantation accepted.
• 202, Application instantation accepted.
• 400, bad request.
• 202, Application instantation accepted.
  For the second question, I think It should return 409, just to let the developer know that this instances is already Instantiated.