Is being RESTful that important?

Question

I'm working on a web based application which uses a JSON over HTTP based API to communicate between the server and the client. The goal being that multiple clients can be developed with different goals (online web client, offline desktop client, or third party created) using the same online data to be shared through this web service.

Right now the communication between the client and server is sent via POST only through a system that works well. I read quite a bit of information about REST and being RESTful with HTTP using PUT, GET, POST, and DELETE. I could separate my API into these different categories, but it means more code and some changes to the API.

My question is: how important is it for a HTTP based API be RESTful? Is it a recommendation, an option, or a near necessity?

Thanks in advance.

Answer 1

It is a recommendation. I am glad you did not go into how RESTful you need to go into as there is something called Hi-Rest and Lo-REST. You can get more information from googling. Some industry veterans I know do not much care about this, but I do find staying as close to html and http will help you in the long run and simplifies many things.

Answer 2

One (of the many) things to consider with service API's is the ease in which they can be consumed by your end user. REST is gaining a very strong tooling presence.

By far the largest dev group out there is the .NET dev group, and with ADO.NET for services (Astoria) consuming REST using Linq is very simple and very elegant.

Answer 3

It's an option amongst several for exposing a web application as a web service with a well-defined API. Other options include:

1. No API - The application has no real way to be used as a component in other distributed systems
2. SOAP - An XML format for defining API remote calls
3. JSON - A compact format for information exchange that can be built on to create a custom API format (or used to build a REST system if you wanted)
4. Many other forms of remote procedure calls and information exchange mediums.

REST has a nice ideal behind it, but that doesn't mean you have to provide a REST API for your application. If the gain isn't worth the extra effort, don't bother.

Answer 4

I would submit that it's a nice to have but not a must. In my experience adding this architecture increases the scope and complexity of the project, but it does add a degree of elegance to the whole. I would say if you've got the time and budget on the project, go for it, if not don't worry about it.

Answer 5

As a die-hard RESTafarian I'd say use HTTP (the REST protocol in question) to its full extent. Why? Well, I'll show you two snippets from an email exchange I had yesterday with a good friend of mine who's seriously clever (and used to be a professor of IT, still lectures, still kicks ass wherever he goes) ;

Yesterday I passed an important milestone for my mappodrhom
application: I can now launch long-running background computations
into a worker pool. When they finish, the workers POST back their results directly into the REST resources. Which triggers more background processing, all controlled by a dependency graph.

And the interesting aspect is that this RESTful backgrounding is
actually independent from my particular application. But I am
currently too tired to completely grasp the consequences :-)

The consequences in question are huge (it's a REST framework with lots of little stacks and events and services and apps, all with their own discoverable URIs, all with the same unified interface), and in terms of extensibility and scalability it is simply unmatched in its simplicity. If your application is a dinky little thing that will never travel places or meet hot chicks, yeah maybe you don't need it. But then, I've said the same, and all of a sudden found myself on a train to Paris with a cute girl that is a secret spy for the Russians, and well, one thing led to another...

Here's my reply, with some of my own experiences ;

I think this sounds (pardon my French) f***ing awesome! I'm experiencing similar things with my own REST stuff, where because the middle layer is so thin and transparent, I can just extend things the way I need them without worrying too much about the infra-structure. It's such a freedom, such a kick-ass cool thing that my brain is about explode, and a worrisome curiosity to why more aren't doing it?

In short, doing REST only half-way is just like not really doing it at all. You're just shifting your stuff over a different pipeline, missing out on a simplified API into a state-machine, semantics- and implementation decoupling at the core, working with the principles that built the net (and hence I'd say you've got rather proven ideas behind you), the unified interface, and having URIs as part of your modeling.

I know it's popular to say that you can pick and choose, that it's all just options. It's not. REST only makes sense by using it fully, but as to convincing you to actually stretch your brain a bit further and do something clever, I can only dare you to cut through the FUD (that it's all about RPC, only GET and POST necessary, you don't need it all, equivalent to JSON, SOAP and other ilk, etc.), and be smarter about how you make applications. Yeah, I dare you all!

Answer 6

Unless you are going to take advantage of hypermedia then I wouldn't bother trying to conform to the REST constraints. Hypermedia is the piece of the puzzle that makes the system greater than the sum of its parts.

You are free to pick and choose which of the REST constraints you want to respect in your architecture, just note that to be able to call the end result RESTful, the only optional constraint is "code-download".