I'm starting to study web APIs a little deeper and I was a bit in doubt with the following question: I work with ASP.NET WebAPI and therefore with object-oriented. I have in my solution a domain project containing domain types with their behaviors encoded in them and everything.
What happens is that reading about APIs I've heard of the Richardson Maturity Model that categorizes API's into four levels:
- Level 0 (RPC): We use HTTP only as a means of sending function calls to the server. We only have one URI.
- Level 1: We split the application into resources and have several URIs, one for each resource, but we also use the URI to describe the action to be performed.
- Level 2: We use HTTP methods to describe the action to be performed on each resource and the action is no longer part of the URI.
- Level 3: Use hypermedia to tell what can be done after the action to be taken.
From what I understood from the book the ideal is to have the highest level possible. It turns out that it seems to me that when using Level 2, the use of object orientation is compromised.
What I've read out there has been some people saying that REST and HTTP are just for transferring resource state and this goes against the idea of object-orientation to modify the state of objects through their methods instead of simply access the fields. That is, using object orientation right, instead of accessing the fields of an object, we execute a method and as a consequence the state of the object can change. An API that is already at RMM level 2, on the other hand, would modify the state of a resource by sending a PUT request that would simply swap the field values.
I did some research on this and saw a video of Jim Webber saying that the idea is that we use HTTP to actually transfer documents between the client and the server but that these transfers have side effects causing actions on the server. I thought about this and wanted to know if I understood correctly how to reconcile Web APIs, REST and Object Orientation.
What I thought was this: Assuming the system needs to manage bank accounts and has a Account type representing an account and a Transaction type representing a transaction. We then have a method in type Account that receives another account and a value and performs a transfer. It would look something like:
Transaction transferTransaction = account.Transfer(anotherAccount, amount);
This, from what I understand, would be the way to do this in object orientation. We're not going to deal with type fields directly, let's leave business logic within domain types.
The point, however, is this: upon reaching RMM level 2 it seems to me that I would have to do the following in the Web API: create a resource transaction representing a transaction and then perform a POST that creates a transaction sending the data of the involved accounts and the value. Something like:
POST /api/transactions HTTP/1.1
Headers
{
"originAccountId": "1",
"destinyAccountId": "2",
"amount": "50"
}
From there on the server we would have a more or less like this (very simplified, no exception handling or other things):
public IHttpActionResult TransferFunds([FromBody] TransferDto transferDto)
{
Account originAccount = accountRepository.Get(transferDto.originAccountId);
Account destinyAccount = accountRepository.Get(transferDto.destinyAccountId);
Transaction transferTransaction = originAccount.Transfer(destinyAccount, transferDto.amount);
transactionsRepository.AddTransaction(transferTransaction);
return Created(location, transferTransaction);
}
In this way, we have resources, we use HTTP methods, but we still leave the business logic encapsulated in the domain. The idea is that we transfer a representation of a pro server transaction and as a side effect of this document submission, the server performs actions in the application domain.
Is this really the idea to work with Web API's, REST and Object Orientation? Is there any problem with that? Are there any other issues to reconcile REST and Object Orientation?