For those that know me, you know how strongly I believe in the power of the style of Representational State Transfer (REST) as the right way to serve the API. You know that I tend to divvy up each twenty-four hour day between RESTing and resting. You may thus be surprised to learn that I believe that REST is not the solution to everything. Blasphemy, you say? Allow me to explain.
A toasty example
For this example, consider the toaster. It solves an important problem in that it transforms breads into toast. Excellent, I am a fan of toast. We can extend this solution further – for the bagel lover, they have created a button that enables bagel toasting abilities. However, when we consider the domain of warming up other foods, it becomes a bit more of a stretch (shrimp? celery? macaroni and cheese may be a problem, but I believe the outcome would still be delicious – disclaimer, don’t try this at home). One could even argue you could solve world peace by providing bread-toasting abilities all over the world – end world hunger and untoasted bread in one fell swoop. However, there are some things toasters simply can’t solve – like finding words that rhyme with orange. Toasters are complementary to this problem, at best.
Where REST works and does not work
To understand where REST does not work, you must first understand where REST excels. REST revolves around two central pieces – the resource (akin to a real life object), and the simple actions of CRUD (create, read, update and delete). One of the best charts to refer to is the following (from Wikipedia), which maps HTTP verbs to object types:
|Collections/bread||List of all items||Replace the entire collection||Create a new entry in the collection||Delete the entire collection|
|RESOURCE/bread/1||Retrieve the one resource||Replace the item if it exists, otherwise, create it||Not generally used||Delete the element|
There are plenty of ways to get into trouble with REST, but there are creative and innovative ways to mitigate this. For example, batching can become problematic, depending on back-end behavior. I explored this issue at an API Craft conference – if we transfer an entire diagnostic imaging study from one place to another, and we have a RESTful interface to create a study, series, and individual instances, how do we do this where it is efficient, that doesn’t suffer from race conditions, and that won’t return premature results before the entire study has been transferred? Some RESTful ways to approach this include having special transfer resource end-points, or through the use of locking. It may not be RESTful, but it is RESTy (there’s a difference, see Stephen Colbert’s thoughts on “truthy“). I’ll explore the topic of innovative methods to accomplish complicated goals in a future post.
REST will break down when we are either dealing with unconventional things, or with unconventional verbs.
- An unconventional thing would be the Image Display actor in the IHE Radiology IID profile. Here, you are not manipulating an object, you are not even retrieving it – you are asking this object to take control of your client to perform some actions. This does not make any sense to do this RESTfully.
- An unconventional verb would be, for example, “transfer me to over there”. It is not one of the simple RESTful verbs (create, read, update, or delete) – it actually is a compound set of actions. It may also require some work for the client to do to accomplish. Because of this, on it’s own, it cannot be RESTful.
REST will work, beautifully, in many projects, but it is not the solution to end all solutions. Consider it for all your great projects, but do not force it if it does not fit – it will stick out plainly, and your application (and constituents) will pay the price. If it fits, though, it will become a thing of beauty.