Mapping of operations via actual endpoint path instead of operationID

[csadorf]

Currently the proxy service (and thus the SDK) uses the operation id instead of the path documented in the standard app api to make requests to an app.

Example:

python-sdk/marketplace/app/v0/object_storage.py

Line 19 in 5923469

self._proxy_path("listCollections"),

I propose to use the actual paths, not the operation ids, because

1. The operation ids are actually not very visible in the standard API viewers (swagger, redocly).
2. The paths were designed to follow RESTful principles (represent resources, not actions).
3. I believe it would be very surprising to app developers that they need to translate the API in such an unorthodox way.

However, I'd be interested to hear the arguments for the choice of using the operation ids. @pablo-de-andres @yoavnash Can you comment on this?

[pablo-de-andres]

So the correspondance would have to be from the operation ids in the specification of the registered app to the paths of the SDK, right? Apps would still indicate the capability in the operation id when they register?

I don't see why not, it should not require much change.
If we want to move forward with this, I would suggest moving it to the GitLab issue board.

[csadorf]

Just to make sure we are on the same page, as an example, to list all available transformations, with my proposed change one would make the following call to the proxy:

api/applications/proxy/{app_id}/transformations/

instead of

api/applications/proxy/{app_id}/listTransformations

Once you confirm I can create an issue on the GitLab issue board.

[pablo-de-andres]

Yes, I agree. I just meant that registering app will still use operationIds

[csadorf]

I've created the corresponding issue on GitLab: https://gitlab.cc-asp.fraunhofer.de/MarketPlace/platform/issue-reporting/-/issues/130