Currently the Edge Application Management API for retrieving app instances requires the client to specify the AppId. If the AppProvider has multiple different applications they care about, then the AppProvider needs to: 1) call the getapps API to get the IDs for their apps, 2) for each appId call the get appinstances API. This requires some logic client side and the overhead of multiple APIs calls. Or, if the client is really basic (auto-generated, etc), then the user themselves must run the getapps API, then copy the AppId, then paste it into the get appinstances API, and potentially do that multiple times.
It is very common for an AppProvider to have multiple applications, so this is a common scenario. Consider also that every client (web, cli (different languages)) will need to reimplement this same logic of getting the App IDs and looping over them.
Possible evolution
I suggest that we move the appId in the current get /apps/{appId}/instances path into the query parameters, so it is treated as an optional filter, much like region and status are filters for get /edge-cloud-zones. The new api path will then be get /appinstances. This will allow for a single API call to get all or a filtered set of App Instances.
For consistency, we will also need to:
change post /apps/{appId}/instances into post /appinstances, moving the appId into the request body.
change delete /apps/{appId}/instances/{appInstanceId} into delete /appinstances/{appInstanceId}. I believe this is actually more accurate because appInstanceId by itself uniquely identifies the app instance, and appId is not necessary.
Problem description
Currently the Edge Application Management API for retrieving app instances requires the client to specify the AppId. If the AppProvider has multiple different applications they care about, then the AppProvider needs to: 1) call the getapps API to get the IDs for their apps, 2) for each appId call the get appinstances API. This requires some logic client side and the overhead of multiple APIs calls. Or, if the client is really basic (auto-generated, etc), then the user themselves must run the getapps API, then copy the AppId, then paste it into the get appinstances API, and potentially do that multiple times.
It is very common for an AppProvider to have multiple applications, so this is a common scenario. Consider also that every client (web, cli (different languages)) will need to reimplement this same logic of getting the App IDs and looping over them.
Possible evolution
I suggest that we move the appId in the current
get /apps/{appId}/instancespath into the query parameters, so it is treated as an optional filter, much likeregionandstatusare filters forget /edge-cloud-zones. The new api path will then beget /appinstances. This will allow for a single API call to get all or a filtered set of App Instances.For consistency, we will also need to:
post /apps/{appId}/instancesintopost /appinstances, moving the appId into the request body.delete /apps/{appId}/instances/{appInstanceId}intodelete /appinstances/{appInstanceId}. I believe this is actually more accurate because appInstanceId by itself uniquely identifies the app instance, and appId is not necessary.Alternative solution
None.
Additional context