Q:

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

A:

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

