RESTful compliant design

问题:

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 ...

回答1:

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).

回答2:

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