modeling VERB like api

[J S M]

Hi All,

Just wanted to get the communities feedback on a functionality such as 'transfer funds'.

The functional requirement is to transfer funds from one account A to another B where we can consider the account as resources. 

The accounts can be within a local db or on a remote db.

How do you design and implement above requirement?

This is my thoughts on design and implementation:

API 

I would have an API like 

POST  /api/transfer?fromaccount=133&toaccount=423&amount=1000

or

POST /api/transferMessage?fromaccount=133&toaccount=423&amount=1000 //to make it more clear that its a message to transfer

and implement transfer funds as a message, i.e

I would send out a message and return an id of the message for correlation

like 

DEBIT ACCT 133 1000

CRDIT ACCT  423 1000

So the actual debit and credit will be implemented in a transnational context to ensure integrity of the transfer.

Then after transaction completes, I will post a message to the messaging system with message id and transaction status.

So the implementation of transfer funds will be Message resource rather than the account.

Any thoughts, suggestions on similar kind of API design.

Let me know if you need clarification of the above.

-JSM

[sune jakobsson]

First of all, I would avoid putting the account numbers and amount in the URL.

Put them in a body where you can verify their authenticity, so than you are sure no tampering occurred. 

You also need to seriously consider idempotency, in case "someone" retries the request. 

Sune

--
You received this message because you are subscribed to the Google Groups "API Craft" group.
To unsubscribe from this group and stop receiving emails from it, send an email to api-craft+unsubscribe@googlegroups.com.
Visit this group at https://groups.google.com/group/api-craft.
For more options, visit https://groups.google.com/d/optout.

[J S M]

Thanks Sune, Both are excellent points and noted.

I agree idempotency needs to be implemented but would that impact how the API is designed? if so, what would the API be like? 

To unsubscribe from this group and stop receiving emails from it, send an email to api-craft+...@googlegroups.com.

[J S M]

Since the API is just message facade, would'nt successfully getting a message id considered to be transaction complete from the users point of view.

Then the implementation needs to ensure idempotency as a default behaviour for this functionality. 

On Monday, August 8, 2016 at 4:15:18 PM UTC+5:30, sune wrote:

To unsubscribe from this group and stop receiving emails from it, send an email to api-craft+...@googlegroups.com.

[sune jakobsson]

There are way too many places a message can get lost, chopped or copied, and it will be since we are talking about direct money.

What will the client do if it assumes that the transaction was successful, yet "someone"TM did a man in the middle attack?

What will happens if the client dies during the call, there is a reason why we desire ACID properties on the transaction.

Sune

To unsubscribe from this group and stop receiving emails from it, send an email to api-craft+unsubscribe@googlegroups.com.

[J S M]

Would'nt that be considered failed message delivery? assuming we check the integrity of the message, we fail the delivery of message so that user can retry?

[sune jakobsson]

You might find some inspiration here: http://technical.openmobilealliance.org/Technical/release_program/docs/PaymentREST/V1_0-20130924-A/OMA-TS-REST_NetAPI_Payment-V1_0-20130924-A.pdf 

In this we used three references, and did the transaction in multiple steps. First reserving the amount, and then doing the actual transaction, and finally the client could check that all went well. 

Think of a scenario where two or more clients on "slow/mobile" connections simultaneously are trying to withdraw amounts that are more than what the accounts holds.

Sune

To unsubscribe from this group and stop receiving emails from it, send an email to api-craft+unsubscribe@googlegroups.com.

[J S M]

Thanks Sune.