Do intent resources exist in REST?

Question

In investigations into REST, I've seen a lot about CRUD vs REST (see Difference between REST and CRUD) and how REST is not CRUD.

I've come across a couple of articles that talk about exposing intent resources and I'm trying to understand what is meant by that.

The best I can understand is that this means the REST API manifest itself as a more coarse-grained API which does not involve the direct manipulation of domain objects, like a CRUD api would.

For example, assume a REST API on top of a banking infrastructure, which allowed the client to transfer money between accounts. Under the hood, the banking infrastructure has no concept of a transfer, it only understands transactions and a transfer is really a debit on one account and a credit on another.

SO the rest API may expose something like /mybank//transfer to which you could post a document containing the necessary transfer details (from account, to account, amount etc). The banking infrastructure would then create the necessary transactions.

Is this what is meant by intent? From a data model perspective, transfer objects don't exist, but the REST api exposes them as a representation of what the customer wants to do?

Answer 1

In a typical n-layer infrastructure, you're going to see arrangements like this

database <---SQL---> DAL <---CRUD---> Service Layer <---BUSINESS OPS---> REST API

It is the BUSINESS OPS communications that these articles are associating with the word "intent." It means that, instead of requiring the client to know all of the necessary CRUD calls to perform a business operation, the client requests the business operation itself, and the Service Layer works out what is necessary in the way of CRUD calls and transaction scopes to accomplish it.

Answer 2

Is this what is meant by intent? From a data model perspective, transfer objects don't exist, but the REST api exposes them as a representation of what the customer wants to do?

That's a pretty good summary of what the authors meant. Because the API acts as an abstraction sitting in front of the real application, you can provide to the API resource a single message (representation) that describes a complex combination of actions in the server, and the implementation of that resource can negotiate with the business system(s) on your behalf.

The implication being that you can deploy new implementations of the business systems and new implementations of the API resources, without concern about breaking any of the existing clients (because the clients only have access to your API, they cannot detect implementation changes on your side).

That said, there's nothing particularly REST, or even Web, about this. An "intent" message delivered to an API exposed as an RPC endpoint would give you the same benefits.

The main lesson is that you are not required, or expected, to match every create/read/update/delete of a resource 1-to-1 with a create/read/update/delete message in your data store.