First let me say, I love REST. I really enjoy its implementation simplicity and the fact that it’s mostly based on HTTP, for which frameworks have been developed and bullet tested for quite some time. I can’t same the same for SOAP and its convoluted related set of standards. Complexity is never good, but its especially not good when it’s not needed to accomplish a particular task at hand. That’s how SOAP and WS-* feels to me. Out of hundreds of times that I was forced to use it, there might have been a handful of valid scenarios when a simpler solution wouldn’t suffice.
So now that I got the fact that I enjoy REST out in the open, I feel that RESTful architectures need more time to evolve and develop a set of patterns. There just isn’t enough empirical information at this point to truly come up wit a set of patterns. Yes, there are books that are great and various other sources of information which help, but I wouldn’t per say call them real architectural patterns at this point, more like a set of experiences developing one or two applications that are labeled as patterns because of its buzzword status and ability to sell books. Patterns are extracted through years and years of empirical information gathering.
Today I was working on an interface, and trying to follow the good ol’ RESTful idioms to design a RESTful API for a particular service. I quickly realized that the constraints of destructive and non-destructive operations bound to particular verbs is a beauty when in its pure form, but don’t always elegantly allow you to model a use-case.
Take my use case as an example. We have a graphing services API which provides graphs to application clients. These clients can be a web front end, or any other client of choosing. Graphs take time to generate, so we want to create the graph resource on a PUT request and then expose a URI with which this graph can be accessed. Easy enough, sure, this is programming REST 101. But here is a catch. Depending on the resource, its lifecycle state changes based on various constraints. One of those resources has a constraint that it can only ever be viewed once and must be destroyed or not allowed to be accessed ever again. So for each graph request, we PUT and GET. But that means that the GET operation is now a destructible operation, which is supposedly against RESTful principals. Someone mentioned to me that such operations should be put behind a POST request, though you generate and return the resource. That’s fine, except there are constraints. If this resource is an image, which is what it is in the graph’s case, it must be embedded in the src=”uri” attribute of the image element in the html page. So can’t POST there. But even if we can use a POST in this case, what about the case where we want a resource accessed a certain amount of times, or what if we want to track the amount of time this resource is accessed, or what if accessing the resource is a stateful operation which modifies other state, whether its own resource’s state or some other resource’s state. One will say that something’s amiss here, but that’s not true. In imperative languages, state is king (not that it’s a good thing), but it’s really easy to model real world interaction scenarios. Where looking at something, or someone, changes some property about what ever you’re looking at. If a pretty lady looks at a guys (who’s a resource), his state will change or it will trigger an action, he will either perform an action, like going over and talking to the lady, or get nervous and start sweating, either one of these actions where triggered by resource view operation. Sorry, maybe it’s not the best example, but the only one that popped into my head at this time of night.
Now, you get my point? I think REST is great, but the lesson here is that you should approach it just like anything else, with caution. When you see something that can’t be done with RESTful purity, don’t beat yourself up. REST is not yet fully mature and we are yet to discover things we can and cannot do with it given today’s interpretation of what it should be. Things change with time, so just do what makes sense today.