3
I’m starting to study web Apis a little more in depth and I was a little bit in doubt with the following question: I work with ASP.NET Webapi and therefore with object orientation. I have in my solution a domain project containing the domain types with their coded behaviors in them and everything else.
What happens is that reading about API’s I heard about the Richardson Maturity Model that categorizes API’s into four levels:
- Level 0 (RPC): We use HTTP only as a means of sending calls to server functions. We have only one URI.
- Level 1: We split the application into resources and we have several URI’s, one for each resource, but we also use the URI to describe the action to be executed.
- Level 2: We use HTTP methods to describe the action to be executed on each resource and the action is no longer part of the URI.
- Level 3: Use of Hypermedia to tell what can be done after the action to be taken.
From what I understand of the book the ideal is to have the highest level possible. It seems to me that by training level 2 the use of object orientation is compromised.
What I’ve read around is some people saying that REST and HTTP is only for transferring state of resources and this goes against the idea of object orientation to modify the state of objects through their methods rather than simply accessing the fields. That is, using right object orientation, rather than 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 level 2 of the RMM, on the other hand, would modify the state of a resource by sending a PUT request that would simply exchange the values of the fields.
I did some research on this and I 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 a little about it and wanted to know if I understood correctly how to reconcile Web API’s, REST and Object Orientation.
What I thought was this: Assuming the system needs to manage bank accounts and has a type Account representing an account and a type Transaction representing a transaction. We then have a method on type Account that receives another account and a value and makes a transfer. It would be something like:
Transaction transferTransaction = account.Transfer(anotherAccount, amount);
This, as I understand it, would be the way to do this in object orientation. Let’s not deal with the fields of types directly, let’s leave business logic within the domain types.
The point, however, is this: when I get to level 2 of the RMM 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 performing a POST that creates a transaction by sending the data of the accounts involved and the value. Something like:
POST /api/transactions HTTP/1.1
Headers
{
"originAccountId": "1",
"destinyAccountId": "2",
"amount": "50"
}
Then on the server we would have a method more or less like this (well simplified, without treatment of exceptions 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);
}
So we have Resources, we use HTTP methods, but we still leave business logic encapsulated in the domain. The idea is that we transfer a representation of a transaction to the server and as a side effect of this document sending, the server performs actions in the application domain.
Is this really the idea to work with Web API’s, REST and Object Orientation? Is this what I did wrong? There are other problems to reconcile REST and Object Orientation?
We do not understand much of the subject and what I am about to say is not directly related to the question. There are two things you are trying to achieve and I will give you advice that is more important than the answer. Don’t cling to concepts, technologies, methodologies, etc. So what if you don’t do object-oriented? Using something must have a reason. So what if you haven’t reached the level of maturity that someone has defined? Do what you have to do, do it the right way, do it. Don’t cling to this or that. I’m not saying you can’t study and maybe apply these things, just don’t cling.
– Maniero
Thanks @bigown, I think that’s it. I once read that REST imposes a set of items that the API would need to satisfy, but that it is more important to know the consequences of each item and use only what is really important for the project rather than trying to make the API 100% Restful. Regarding Object Orientation, I usually try to apply the concepts to the extent that we can reduce dependencies and facilitate testing and maintenance of the code later, but I’ve seen that in some cases we can’t do this 100%. Thanks for the advice!
– SomeDeveloper
Your question did not leave much room for an answer, so it fits in a comment: Yes, coordinating business objects designed according to object orientation to respond to a REST request is a good idea. No, there’s no problem with what you did. And no, reconciling REST or Restful and Object Orientation has no natural problem but problems can arise if the concepts are confused - REST is just a service facade; what has underneath can be solved with several paradigms, including with object orientation.
– Caffé
I disagree a little bit with @bigown I think we should always use practices and paradigms. Use the idea that I did the way I did because it does not "fit" certain practice with the requirement, very likely that your understanding or your model can be better thought out. How much the answer I put as an answer to be able to use examples.
– heat