Update SDK to be based on the standard app API

[csadorf]

The Python SDK is currently based on the old MarketPlace API, however it should be based on the revised standard-app-api.

[pablo-de-andres]

Any updates on this? Support needed?

[pablo-de-andres]

I was thinking about how different versions of the standard app API could/should be supported, and I realised this might not be necessary.

The user will provide the application_id of the app they want to interact with. The SDK could then query the platform (specifically, the application service) to get the information about the app, including the openAPI specification. I think this is all that would be needed to know which capabilities a certain app includes.

Another approach (which seems nicer to me) would be to have an endpoint in the application service that returns the supported capabilities given an application_id (the endpoint would require authentication and could check that the user requesting it has purchased the application)

[csadorf]

Any updates on this? Support needed?

@pablo-de-andres Yes, there are a few not clearly identified blockers. So far, I think I implicitly considered this to be blocked by materials-marketplace/standard-app-api#19 and materials-marketplace/standard-app-api#28 . However, I am starting to question the utility of both of these PRs and also question whether this particular issue is truly dependent on those. What do you think?

[pablo-de-andres]

I don't really see a dependency, since the SDK will only be used to make contacting the proxy easier, and I would say has no need to know how the app has implemented the capabilities.

But if you see my last comment, I actually wonder if we do need to make it directly dependent on the standard app API, or just use the platform (which will be the one checking that the apps comply with the API)

[csadorf]

I don't really see a dependency, since the SDK will only be used to make contacting the proxy easier, and I would say has no need to know how the app has implemented the capabilities.

That's correct, but I was hoping to use the reference implementations for testing in this context. However, there might be other/better options.

But if you see my last comment, I actually wonder if we do need to make it directly dependent on the standard app API, or just use the platform (which will be the one checking that the apps comply with the API)

I think we should make it a direct dependency since part of the idea is to be able to use the pydantic models for typing.