Should the PISP implementation live in the `sdk-scheme-adapter`, or should we make a new `thirdparty-scheme-adapter`?

[lewisdaly]

Request:

As for the sdk-scheme-adapter (which the mojaloop-simulator uses behind the scenes), since the PISP API will be quite a different from the Mojaloop API, should we:

Option 1:

• Add the new PISP functionality to the existing sdk-scheme-adapter by way of new state machines to model the PISP and DFSP who wants to support PISP

  Note: this is the decision we are working with for now, but this will be revisited at a later date depending on this DA decision

Option 2:

• Create a new scheme adapter (say, thirdparty-scheme-adapter) to support the thirdparty functions

  Note: Keep in mind there are actually 2 sub-apis of the new 3rd party api: the PISP side, and the DFSP who wants to allow PISP functionality side. So we may even decide we need 2 new adapters...

• Factor out the common code that will inevitably be shared between the 2 (or 3) scheme adapters

Artifacts:

• api-collision doc - this doc outlines in more detail the challenges here.

See the above doc for more details, but also:

• Example 1 - PUT /authorizations/{id}

• Example 2 - PUT /parties/{type}/{id}

Decision(s):

• [ ] Actual decision made as a result of discussion

Follow-up:

• [ ] Alternative actions

Dependencies:

• [ ] If Applicable

Accountability:

• Owner: @lewisdaly

Notes:

[lewisdaly]

We discussed this further on our DA Meeting on 26/08/2020.

Some of the key points were noted:

1. In order to take advantage of Typescript, and to help speed up development, the PISP workstream has gone ahead and separated out the thirdparty-scheme-adapter already.

2. One of the challenges identified with the "multi-scheme-adapter" approach was for cases where there are shared resources between the APIs, such as GET /parties/{type}/{id}.

Our decision to break the Thirdparty API into it's own API (and not extend the FSPIOP-API) was predicated on the idea that "not all participants will want thirdparty functions", and therefore shouldn't have to worry about them. As a part of the decision to keep a separate Thirdparty API, we decided that some resources would be duplicated between the two.

This could lead to problems down the line, where callbacks to some resources might not be able to reach their desired destination: for example if a DFSP needs to listen for PUT /parties/{type}/{id} callbacks for both the FSPIOP API and the Thirdparty API, it may not be possible for DFSPs to route such callbacks to the right place.

The more I think about this issue, the less I think it's related to the scheme-adapters, but is more related to API design. We need to be careful not to be too prescriptive with how we think DFSPs will run their services - be they separate, all together, behind an API Gateway: it shouldn't concern us, and we should, in our API design, allow for anything.

@lewisdaly will spend more time working on some diagrams and design documents, and come back to the DA shortly

[lewisdaly]

Update as of 02/09/20:

See this draft document for the latest thinking and some examples of mitigations.

[lewisdaly]

We discussed this on 02/09/20.

In principle, it was decided that the fact that there are shared resources between APIs is coincidental, and should not dictate the way DFSPs and PISPs run their services - whether or not they share infrastructure to handle the common resources between the APIs is up to them.

We still have more to discuss around ensuring that APIs can be appropriately distinguished between (there was some talk of using the vendor tag in the Accept and Content-Type headers).

It was agreed that we will revisit this at a later date once we have more work done on the separate thirdparty-scheme-adapter, but in principle, there is no reason that we shouldn't have a separate scheme adapter.

[mdebarros]

We discussed this on 02/09/20.

In principle, it was decided that the fact that there are shared resources between APIs is coincidental, and should not dictate the way DFSPs and PISPs run their services - whether or not they share infrastructure to handle the common resources between the APIs is up to them.

We still have more to discuss around ensuring that APIs can be appropriately distinguished between (there was some talk of using the vendor tag in the Accept and Content-Type headers).

It was agreed that we will revisit this at a later date once we have more work done on the separate thirdparty-scheme-adapter, but in principle, there is no reason that we shouldn't have a separate scheme adapter.

I agree with this, it's really up to the Hub Operator how they wish to segment their APIs, and present them to their customers.