Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

EAM: Suggest that POST appinstance targets a single EdgeCloudZone #256

Open
gainsley opened this issue Jun 7, 2024 · 1 comment · May be fixed by #316
Open

EAM: Suggest that POST appinstance targets a single EdgeCloudZone #256

gainsley opened this issue Jun 7, 2024 · 1 comment · May be fixed by #316
Labels
correction Suggesting corrections of API specification or indicating misalignment with API design guidelines

Comments

@gainsley
Copy link
Collaborator

gainsley commented Jun 7, 2024

Problem description
Currently POST app instance targets multiple EdgeCloudZones, which creates some confusion as to what the correct behavior should be in some cases. The reason it is confusing is because we are effectively combining multiple API calls into one, where any single API call my behave differently from the other.

For example, suppose one of the EdgeCloudZones specified does not exist, but the other ones are ok. Does the API fail just one, or fail all? Is the return value 202 or 400?

Expected behavior
We should design APIs to be as simple as possible and do just one thing. The caller can manage calling the API multiple times if needed. So I suggest the POST app instance API target only a single EdgeCloudZone.

Alternative solution
Extensively document the expected behavior in various corner cases. Not really recommended.

Additional context

@gainsley gainsley added the correction Suggesting corrections of API specification or indicating misalignment with API design guidelines label Jun 7, 2024
@gainsley
Copy link
Collaborator Author

This is still an unresolved issue.

I suspect the intent was to allow deploying a large number of instances all at once. If that is still needed, then we need to change the response object to allow including both the successful AppInstanceInfo and an array of failure objects that includes the AppId, ZoneId, and error message. We may also want a mass-delete API, otherwise if the client can delete one-by-one, then the client can also certainly create one-by-one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
correction Suggesting corrections of API specification or indicating misalignment with API design guidelines
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant