CODEWITHSUNDEEP
httprestpostsoa
jean
jean

Reputation: 251

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.

PUT /Bank/john

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

DELETE /Bank/john

GET /Bank/john

POST /Bank/john

action=withdraw&value=10

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

Upvotes: 2

Views: 1990

Answers (2)

nategood
nategood

Reputation: 12005

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

Upvotes: 3

shenhongzhou
shenhongzhou

Reputation: 63

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

Upvotes: 1

Related Questions