问题
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
来源：https://stackoverflow.com/questions/9540653/restful-compliant-design