Web API's, REST and Object Orientation


I'm starting to study web API's a little deeper and I was a little doubtful 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 behavior coded in them and everything else.

What happens is that reading about API's I heard about the Richardson Maturity Model which categorizes API's into four levels:

  • Level 0 (RPC): We use HTTP only as a means of sending calls to functions on the server. We only have one URI.
  • Level 1: We divide the application into resources and we have several URI's, one for each resource, but we still 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 of hypermedia to say what can be done after the action to be taken.

From what I understand from the book, the ideal is to have the highest level possible. It turns out that it seems to me that when I reach level 2 the use of object orientation is compromised.

What I've read out there was some people saying that REST and HTTP are just for transferring state of resources and this goes against the object-oriented idea of ​​modifying the state of objects through their methods instead of simply accessing the fields. That is, using right object orientation, instead of accessing an object's fields, we execute a method and as a consequence the object's state 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 a little 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 since these transfers have side effects causing actions on the server. I thought about it a bit and wanted to know if I understood correctly how to reconcile Web API's, REST and Object Orientation.

What I thought was the following: assuming that the system needs to manage bank accounts and has an Account type representing an account and a Transaction type representing a transaction. We then have a method of type Account that takes another account and an amount and performs 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. We're not going to deal with type fields directly, we're going to leave the business logic inside the domain types.

The point, however, is this: when I reach 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 by sending the account data involved and the value. Something like:

POST /api/transactions HTTP/1.1

    "originAccountId": "1",
    "destinyAccountId": "2",
    "amount": "50"

Then on the server we would have a method something 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);
    return Created(location, transferTransaction);

That 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 transaction to the server and as a side effect of this document submission, the server performs actions in the application's domain.

Is this really the idea for working with Web API's, REST and Object Orientation? Is there any problem in it? Are there other problems to reconcile REST and Object Orientation?


Very well placed @Leandro and I think this is what generates doubts in a lot of people. It is perfectly possible for the two worlds to coexist mainly because the OO will stay in its domain keeping the business logic. The problem is that it generates confusion and ends up thinking that a resource is usually a model of your domain, for some situations it is, but it is just a representation of your domain.

We could reflect and generate the following resource

POST /api/accounts/{id}/transactions HTTP/1.1

    "destinyAccount": "2",
    "amount": "50"

Your solution is also good. But the main thing is to know that a model is not always a resource so that a resource will not always be linked to a model.

Scroll to Top