277 first pass at breaking down API calls and Roles

mojaloop / pisp-project

PISP - Payment Initiation Service Provider integration with Mojaloop

Other

9 stars 12 forks source link

277 first pass at breaking down API calls and Roles #5

Closed lewisdaly closed 4 years ago

lewisdaly commented 4 years ago

Closes #277

Lists out all existing FSPIOP API calls, and newly proposed PISP calls
Update roles doc based for new PISP endpoint: thirdPartyRequest/transaction

I'm putting this up as a draft because I'm sure some of these endpoints will change in the next few days with feedback from the CCB and the PISP team.

mjbrichards commented 4 years ago

First thoughts:

A general point: in our world, being able to issue a PUT in response to a POST or a GET implies an ability to be open to further interactions. So we shouldn't allow participants to respond unless they're up for it...
PISP should not be able to respond to a GET /parties, since it doesn't own any accounts...
PISP should not be able to respond to a POST /thirdPartyRequests/transfers, since it can't initiate the transfer process.
I agree that a PISP shouldn't be able to respond to a POST quotes request.
I think our current plan on requesting account balances is that it will be a sub-endpoint of thirdPartyRequests: so the second of your alternatives
We could distinguish between the authorizations forms for DFSP and PISP by allowing only a DFSP to issue a GET /authorizations, and only a PISP to issue a POST /authorizations

lewisdaly commented 4 years ago

PISP should not be able to respond to a POST /thirdPartyRequests/transfers, since it can't initiate the transfer process.

Agreed. I think I had a trailing /{ID} which implied an update, but I've removed that to simply:

- Initiate 3rd party request - `POST /thirdPartyRequest/transaction`

Note: I've gone with transaction here, based on the naming conventions of transactionRequests, but please let me know if this should be transfer instead

lewisdaly commented 4 years ago

Hi all, I was getting mightily lost in this document, so I updated it to use a markdown table, and removed the redundancy in API call lists by collapsing them into one list of calls + permissions.

I hope this is more clear now.

lewisdaly commented 4 years ago

I think this is ready to go for the current state of designs.

I'm sure there are changes to make down the line, but I don't want to hold this up from getting into the PISP repo where it can be useful for the team.