Why I dislike REST

From time to time "PR" words come to live and suddenly they become the "must use" by every developers. We got AJAX, we got Web 2.0, we got MVC and now lately we got REST. Maybe the order is not exactly as I gave it in this list, still those are the "keywords" people used a lot in the web development world. Doesn't matter which language / platform / framework used, if your soft wasn't using those keyword then it wouldn't be considered.

Here I'm already against those words, why? Because at the end of the day what counts is the functionalities your soft offer, not how it's implemented. It is more important that your software do what it is expected to do instead of "looking good on paper".

Let's concentrate on the REST word. REST is nothing else as an "idea" of having simple data access via HTTP. Think about a database, select would be done via GET, update will be done via POST, delete via DELETE, and insert via PUT. So basically we are all covered, we can do all the CRUD operations via HTTP! Great! Yet do you really want to offer full DB access via web? Well, for most the answer is no! At least we should authenticate the request, and already here there is no "standard". Sure you can send the auth via cookie or via a token passed on the URL. But what if I would like to add a "where" clause to my "select"? Oddly enough again there is no "standard" and it's actually not well considered too beside if you want to grab a single item based on the id. Come on, what if my interface offer more than a single id selection? Well out of luck either you develop your own solution or... you do the selection on the GUI side while transferring the whole answer. Now don't pick me wrong some REST frameworks do offer solutions for all those problems but there is no "standard" even if REST is not a standard.

But didn't we had before things like XML-RPC which offered ways to call functions with whatever parameters we would like? Or SOAP which would offer even a self describing API? Don't tell me those are complex to use, or verbose (due to XML), honestly in most case it's not an issue. For the complexity most frameworks do offer pre-prepared SOAP solutions (Java, C#, PHP, etc...) and the verbosity is a non-issue for most.

Where I do agree is that to call SOAP API via Javascript is not really all that fun, and for that REST is much easier. So why not try to combine the flexibility of SOAP and the easy to use of REST? That's what I did, let's call it a JSON / SOAP interface which let me develop simple C# classes with functions which can directly be called from JQuery.

Of course it is not "standard" as it's a self written solution, but don't come with this and try to sell me REST as it's not standard either, and even more you need to describe your API manually, while my own solution produce the documentation automatically with even test pages.

At the end, for me, it's more important to think about your goal, and what would be the best solution in the medium / long term instead of running after the last PR word which may very well end up with a useless tech.