RESTful Web Applications Are Good For You

There’s been some discussion in web development circles recently about whether RESTful (a.k.a Client MVC, a.k.a. Single page) web applications are a good idea. Or, more accurately, whether they’re a better idea than just serving up HTML from the server.

Now, before I give my two cents on this, let’s define what we’re talking about here. Basic pattern behind RESTful web apps is this: the Server exposes a set of REST endpoints which emit XML or JSON (usually the latter), while the Client (which is typically built using some JavaScript MV* framework) consumes said endpoints.

I should note that both sides of the argument make some very valid points. In particular, the side against RESTful web apps points to non-trivial costs (in the form of increased complexity and performance issues) as reasons not to do it for every single app you build.

They make a great point. There is a cost associated with RESTful web apps, just like there is a cost associated with a lot of other things (Domain Driven design is one popular example). If the cost cannot be justified, it shouldn’t be incurred.

That said, I think that this architectural pattern is one of the most exciting trends in software development. Here’s why.

Forcing Function

If you’re building a RESTful web app, you’re forced to think about your domain in terms of resources and simple CRUD operations on those resources. Lots has been written on why resource orientation is a good thing, so I won’t rehash those reasons here. I’ll just say that to me, achieving modularity and loose coupling via resource orientation feels like the least labored way to do it.

In other words, I rarely feel like I’m straining the resource metaphor when I talk about what resources my app would consume/create. I also find it more natural and more straight forward to reason about, especially when compared to other layering or service oriented techniques.

Free API

Another benefit of building RESTful web apps is that you get a set of APIs for your domain for free. Want to build a mobile client? No problem, just use these APIs we already developed and tested. This stands in stark contrast to more “traditional” web applications where exposing your data to other consumers requires a whole new development effort.

Now, I should note that you’ll likely need to bullet-proof your APIs before exposing them to external consumers. After all, we tend to take shortcuts when we have complete control over both the consumer and the producer of the APIs. This is normal and reasonable because the extra level of rigor is simply not needed.

So, you will probably have to go back and add things like additional authentication mechanisms, more robust validations, better logging, more consistent response codes, clearer error messages, etc. That said, the effort to get these APIs prepped for external consumption is considerably lower than building them from scratch.