2

Let's consider I need to develop a REST bank application that allows the creation/destruction of bank accounts as well as the following operations on an account: withdraw/credit/getBalance.

  • Creation of an account

PUT /Bank/john

Here I use PUT instead of POST because this operation is idempotent and because the client is giving the URL

  • Destruction of an account

DELETE /Bank/john

  • GetBalance

GET /Bank/john

  • Withdraw money from an account

POST /Bank/john

action=withdraw&value=10

  • Credit money to an account

POST /Bank/john

action=credit&value=10

Here, I used POST because withdrawal/credit are clearly not idempotent

is it a RESTful compliant way of designing these operations ?

I have the feeling that I am writing something that is RPC-like by putting the verbs (withdraw | credit) inside the action parameter .. and I often read that REST should not mimic the RPC-like style ...

jean
  • 251
  • 4
  • 14
  • I think you need to eliminate the action verb and completely depend (as much as possible) on HTTP methods to say design is REST. – kosa Mar 02 '12 at 21:34

2 Answers2

3

When dealing with REST, it generally helps to start by thinking in terms of resources. In this case your resource is not just your "bank account" but it is a transaction of that bank account.

Deposit

POST /Bank/Account/John/Transaction

currency=USD&amount=10

Withdraw

POST /Bank/Account/John/Transaction

currency=USD&amount=-10

You response should include a Location header to this newly created transaction.

You are creating a transaction. The advantage of this is that you can then reference that transaction as a resource.

GET /Bank/Account/John/Transaction/12345

This could return a record of that exact transaction (e.g. your users generally want a record of debits and credits on their account).

nategood
  • 11,807
  • 4
  • 36
  • 44
  • Thanks nategood. I must admit that this way of designing is not natural for me (I come from the CORBA world ...) but I think that your solution respects the REST architectural principles. – jean Mar 02 '12 at 23:08
  • You'll probably also want to make deposits and withdrawals effectively idempotent (you would want the transaction to happen twice). This can be done fairly easily by creating transactions in a "draft" status and requiring an update (PUT) to commit. Also, for your API to be truly RESTful, you'll need to include the links and forms in the responses. More details at http://www.amundsen.com/blog/archives/1041 – Tom Howard Mar 04 '12 at 21:36
1

I don't think you should add "action=credit&value=10" things. You can create more/longer URIs. For example:

create an account: POST /Bank/Accounts/John
credit money to an account: POST /Bank/John/Money/10
shenhongzhou
  • 63
  • 4
  • Sure it will work ... but as far as I understand the principles, your solution will also break these principles ... – jean Mar 02 '12 at 23:11
  • POST works for crediting money. What would you use to withdraw money? I guess you could POST a negative value. But that seems a little weird. – Francisco d'Anconia Jun 23 '18 at 04:20