The S does not stand for Simple

Interesting:

REST is a vast improvement over complex things like SOAP and CORBA, but I think we still have a way to go before we’ve reached simple. REST is an acronym for REpresentational State Transfer, and I think the “state” part of that acronym gives rise to a lot of incidental complexity as systems grow.

You can think of state as a combination of value and time, and in the RESTful case, the time dimension is almost always “now”. The trouble then comes the absence of a coordinated notion of time.

Almost every program I write today depends on at least one RESTful service, and my program is just one component in an ensemble. As we develop systems that call systems that call systems, what are the odds that everybody participating in the ensemble has the same notion of time? What happens when systems have different notions of time? When we are talking about services in the small, it’s not a much of a concern, but for networked systems in the large, conflating value and time into state makes our systems increasingly difficult to reason about.

System Consistency
Here’s a concrete example: let’s suppose we are developing an e-commerce system to process customer orders. We have a RESTful endpoint that looks something like this:

POST http://api.example.com/orders

{
“product_id”: 12345,
“customer”: {“first_name”: “Ted”,
“last_name”: “Dziuba”,
“shipping_address”: “123 Main St”,
“credit_card”: {“type”: “visa”,
“number”: “0123456789012345”}
}
The obvious problem with this is that we’re given a reference to the product, and not the product itself. Therefore, we need to de-reference product_id to know how much to charge the customer in our order processor:

GET http://api.example.com/product/12345

{
“id”: 12345,
“title”: “Apple iPad Air”,
“price_usd”: 599.99
}
There’s a consistency problem: the price may have changed between the time that we received the order and the time we looked up the product. To patch it up, we attach the product price to the order:

POST http://api.example.com/orders

{
“product”: {“id”: 12345,
“price_usd”: 599.99},
“customer”: “…”
}
Yet, this is not a robust solution. We must attach any state that we need post-transaction. If our analytics department needs to know the product category for their reporting, or if our accounting department needs to know cost-of-goods-sold for revenue calculations, we must attach these as well, as they may change over time. As these requirements grow, you end up sending more and more of the object graph attached to the order, just to maintain consistency for everything that happens after-the-fact.

While this kind of solution may work in the small, consistency-patching complexity will actually grow faster than the system itself. Every new participant in the system must account for consistency semantics for every other service it depends on. If your system has N components, each of which depends on at least 1, and as many as N-1 other components, the lower bound of this complexity is linear, and the upper bound is quadratic.

With apologies to Pete Lacey for the title.