Or, The Web is Biased Towards the Web

The purpose of this posting is to give a counter point to those who make design decisions based solely on the outcome of googling. I have this crazy belief, that when it comes to technology information on the web, that the largest and loudest voices are web developers.   Who are web people?   Bloggers, twitterers, facebookers, ruby-on-rails fanboys, and other people who develop web software.    Well, who does this leave out?  Developers who build embedded systems, real-time systems developers, 3D engine developers, PC applications, and so on.

If you can agree to this belief that there is a bias on the web toward the web, then us nerds have a problem.  A google search for new and emerging technologies can easily confuse and lead astray non-technical decision makers, who are not aware that they will be inundated with web-focused technologies.

The Non-Technical Decision Maker Comes into Play

Unfortunately, in the real world, often the decisions are made by non-technical folks, or those that were once technical, but have grown crusty.  And how do these non technical people come to their conclusions?  Like everyone else: googling. Which leaves them overexposed to web tech.  And then poor decisions are made, because they have no technical compass to help them navigate through these web-laden waters.

So, eventually, the manager types hear the chorus of REST and other ‘Web 2.0′ proponents, and then turn around and push their own team to jump on the bandwagon. If you are lucky, it actually makes sense for your company and app.

Again, the point of this post is to just provide a counter-balance. If I may, let me provide some simple rules to help decide for or against REST adoption.

When to go REST

In general, REST is simple, clear, and healthy way to build some three-tiered web applications. REST concepts map well to database-driven data. Also, providing a comprehensive and easy-to-understand set of rules has immense value for modern web programmers, who have a tremendous bevy of tools and technologies to choose from when building web apps and can easily get lost on the design front.

When you may not want REST

1. When you don’t yet fully understand that REST is not only an emphasis on using the HTTP protocol correctly, but also a comprehensive design strategy that will have implications on your entire application
2. When the API of your app has events (client-directed messages)
3. When you have an existing system that has internal workings that are not already RESTful. If you attempt to make such a system RESTful, you will likely spend a great deal of time refactoring your code, or implementing a huge wrapper on front.
4. When you have a very high rate of RPC messages
5. When you want to offer native language bindings to your API without building the binding yourself (i.e., consider SOAP, CORBA, Etch instead. They have much richer toolchains)

I’ll close with one minor point: regardless if REST is right for your application, the fact that REST has brought attention to using HTTP better is a great thing. Meaningful, nicer-looking URLs, meaningful HTTP error code usage, and in general, the proper usage of the HTTP protocol is most welcome.