Is being RESTful that important? [closed]

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

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!