This is the last of my thoughts on REST (for the time being) after spending a few weeks doing some research and giving it some thought. See the previous two posts for more background.
What About Change?
According to Fielding: “You can’t have evolvability if clients have their controls baked into their design at deployment. Controls have to be learned on the fly. That’s what hypermedia enables.”
I didn’t quite get this at first. That’s the whole point of versions: clients DO have their controls baked into their design at deployment time, and I don’t have any power over how users of my service are going to write their software.
Yes, We Can (Change)
So I did some more research, and found another discussion with Fielding. Take a look at the discussion, especially at comment 21 (trimmed here for brevity):
“Of course the client has prior knowledge. Every protocol constitutes prior knowledge that the client must know in order to make use of that knowledge. REST is intended for long-lived network-based applications that span multiple organizations. If you don’t see a need for the constraints, then don’t use them. I have no problem with systems that are true to their own architectural style.”
As Usual: Do What Works For You
I think the idea here, and it’s starting to make more sense after digesting it, is that
- REST may still require a priori knowledge on the side of a client to use
- REST is not the end-all of API structures and not appropriate to all applications
It is cool, yes, and people like it. But you don’t have to sweat versioning, or sweat following every REST constraint. You can incorporate ideas you find useful, and mention which REST constraints you follow as a shorthand for communication about the architecture of your API.
Your API should do what works for your product. You should do what works for you.