A Noob's Scattered Thoughts on REST

Note: I hope you'll bear with me as I meander through my still very disorganized thoughts on the topic. This post is very much for myself, with the goal of distilling the information floating around in my head into something more concrete and which I can actually make use of...

I have a few projects on the horizon, both at work and on my own, which will involve web services in some form or another. I have to admit, I've never been much of a "web guy" before. My career to this point hasn't demanded that this change, but it looks like it's time for me to move off the desktop at least part-time. So I've dived into web services.

I develop for .NET at work. So while I may explore something else for my personal projects, for work I have to focus on .NET frameworks. Of course REST is all the rage these days, so it's obligatory that I research that. So I've read a number of blog posts describing what REST is about. My assessment of the REST is that it seems like a nice idiomatic design philosophy for a web service that deals primarily with persistent data entities and operations over them.

It seems clear to me though that there must be problems which might be addressed via a web service which aren't necessarily natural to model using REST. Of course the fallback, if one were to decide that the barrier is too great, would be to use some sort of RPC style. RPC comes natural to us developers, of course, because it's essentially just a web-enabled version of the idioms we use ubiquitously in code.

My own feelings about RPC as compared to REST are less critical than many. I understand the philosophical imperative to maintain the webbishness of services operating over the web. However, I also hold very strong to the opinion that solutions should be created using metaphors that lend themselves naturally to the problem space. REST, as defended by many, seems to me to be less about the problem space than it is about the mechanism the solution is built on.

However, if REST can be said to consist of two pillars, resource-orientation and mapping operations to the HTTP verbs, then it seems the later is really the part that seems limiting. After all, a resource is not so different from the "objects" that permeate our code as programmers. But imagine if, in your object-oriented design, you were allowed only 4 methods per object, and each of them had to fit one of four very specific patterns. That feels arbitrarily limiting, doesn't it? It does for me.

Now, having said that, I do see value in keeping things simple. The web is already a high level abstraction. And building convoluted metaphors on top of it that don't map easily to the mechanisms that underly it can cause a lot of unnecessary headaches. I also believe that it may not be unfair to compare RPC-heavy designs to the old style of procedural programming. That is, that they have all the nasty kinds of coupling and inertia, and few of the good kinds. Especially when the data entities involved are mutable.

That last point hits home hard for me, though. And I think it will end up strongly informing how my designs play out. The reason for this has largely to do with how my overall coding style has evolved over the past couple of years. I've found lately that, with the exception of DTOs and the primary domain objects in my solutions, a great many of the objects I work with tend to be immutable. And the algorithmic bits that operate on them tend to come in nuggets of functionality that are highly composable. This strikes me as being fairly compatible with REST's resource-oriented design.

Another factor I have to consider is the frameworks that are available to me. Comparing what I can find on the web about WCF and ASP.NET, the primary non-REST web service frameworks, and OpenRasta.... I have to say that the code and configuration of OpenRasta solutions seems to be much simpler, more elegant, and clearer of intent. This appeals to me greatly. It seems like it would be much easier not only to spin up something from scratch into a working solution, but also to evolve smoothly from my first fumbling attempts through to a final product that still has clarity of structure and intent. If I've learned anything in my career so far, it's the importance of that.

So my initial forays, at least, will likely be based in OpenRasta. If it turns out that OpenRasta can't give me what I need, or that there's too much friction, I'll look for help of course. But I also won't be afraid to try to weave some RPC into my design if it's called for.