Sandbox serves the following resources:
- Demobanks.
- Bank accounts.
- Subscribers.
- Transactions.
- Customers.
- Reports.
The resources are subject to all CRUD operations, via by two types of users: the ‘admin’ and the customers. The admin has rights on all of them.
One of the main differences with the previous versions is the
removal of the “/admin” initial component. If the administrator
authenticates for one operation, then this one is of type admin:
no need for a dedicated and extra URI path component.
For example, mocking transactions in the system was a typical
/admin-operation, but since transactions themselves are resources
and any resource is subject to CRUD operations, then mocking one
becomes just a C operation on the ‘transactions’ resources. If
a test case wants to simplify the authentication - by hard-coding
the credentials, for example - before mocking one transaction, then
it can impersonate the administrator.
Note
POSTing to an endpoint with a trailing $id means
modification of an existing resource.
Demobanks are the main containers of all the other resources. They take configuration values, like the currency for example.
GET /admin/demobanks¶GET /admin/demobanks/$id¶POST /admin/demobanks¶POST /admin/demobanks/$id¶DELETE /admin/demobanks/$id¶Bank accounts collect money of customers and participate in transactions.
The $base is one demobank, in the form /demobanks/$id.
That is due because a bank account must inherit some defaults
from the demobank, like the currency.
GET $base/bankaccounts¶GET $base/bankaccounts/$id¶POST $base/bankaccounts¶POST $base/bankaccounts/$id¶DELETE $base/bankaccounts/$id¶Subscribers are (optional) customers identities for protocols other than the native one.
A subscriber is not required to have a bank account “soon”. Therefore,
it can be created, and later be linked to one bank account. For this
reason, the $base should not mention one bank account.
Note
Creating a subscriber is a time-consuming operation that goes often through slow channels, therefore it should basically never be done more than once.
GET $base/subscribers¶GET $base/subscribers/$id¶POST $base/subscribers¶POST $base/subscribers/$id¶DELETE $base/subscribers/$id¶Transactions are money movements between bank accounts.
For convenience, $base could mention one bank account
to let customers see their transactions without defining “history”
query parameters: like $demobank/bankaccounts/$bankaccountId/transactions.
At the same time, transactions should be easy to query regardless
of whose bank account they involve – for administrative reasons, for
example. Hence, a “global” URI scheme like $demobank/transactions?param=XXX
should be offered as well.
GET $base/transactions¶GET $base/transactions/$id¶POST $base/transactions¶POST $base/transactions/$id¶DELETE $base/transactions/$id¶Customers are persons that can have one bank account. As
with subscribers, $base should not mention any bank account
so as to leave more flexibility to assign new bank accounts to
the same customer.
GET $base/customers¶GET $base/customers/$id¶POST $base/customers¶POST $base/customers/$id¶DELETE $base/customers/$id¶Reports are persistent documents witnessing transactions.
A typical example is a Camt.053 statement. A report lives
even after a bank account gets deleted or a customer leaves
the bank, therefore $base should only mention a demobank
instance.
GET $base/reports¶GET $base/reports/$id¶POST $base/reports¶POST $base/reports/$id¶DELETE $base/reports/$id¶