API Wrapper: Use Case API Initiative (Ongoing)

[richardtreier]

Epic

Description

With our EDC API Wrapper and EDC API Clients underway the goal is to develop an API for Use Case Application developers that can contain a simplified EDC workflow, and more stable API endpoints than our UI endpoints. This is required because our API Wrapper UI API is both tightly coupled to the UI scope and subject to change over time depending on UI needs.

Requirements

• Bootstrap EDC API Wrapper Extension #187

Work Breakdown

• Implement simplified workflow
  • createDataOffer
  • updateDataOffer
  • negotiateContract
  • initiateTransfer
  • transfers
  • catalog
• Decide which other Management API endpoints to wrap
  • Vault Access
  • getContracts
  • getAssets
  • getAssetById
  • getContractById
  • getTransferById
• HttpProxy in Use Case API Wrapper #958

Acceptance criteria and must have scope

• Simplified Workflow working.
• Transferring data is possible.

[richardtreier]

4. Copy all necessary model classes to the Wrapper and add swagger annotations.

To summarize from friday: This is what it will most likely be. We will decide the own data amount to return per endpoint. This might be less than the Management API returns, or more. This makes it so that we can also change the object's structure, e.g. for policies.

We do not need to copy all the classes, but can decide on a per-endpoint basis what the right thing to return is.

For cases with polymorphisms, such as the EDC Expression class we need to provide sum types, so we A) have a decided and clear cut scope we support and B) they can work in the generated clients, as overriding JSON in Java is not easy.

[AbdullahMuk]

As I understand from the current status of the API Wrapper, we have implemented simplified workflow already. Assuming my understanding is correct, we should evaluate what remains to be completed and define the solution proposal accordingly.

Target for evaluation is: Sprint 43

[richardtreier]

As I understand from the current status of the API Wrapper, we have implemented simplified workflow already. Assuming my understanding is correct, we should evaluate what remains to be completed and define the solution proposal accordingly.

Target for evaluation is: Sprint 43

No we have not. The idea is to offer a simplified "createDataOffer", "deleteDataOffer", "listDataOffers" as single API calls

[SebastianOpriel]

@richardtreier what is the status?

[richardtreier]

With upcoming validations of comfortable usage of our APIs with Use Cases also for C-X we are re-doing the requirements engineering for our EDC APIs in context with the newer Eclipse EDC versions and ways of working witht hem.

Thus, I'll be closing this issue for now, as it is rather a "catch-all" planning issue, that never was truly tackled, and is also very old.