I had a very “interesting” discussion with a colleage about an API that he would like to expose through REST. This API is suppose to check a SQL where clause. He suggested to expose it as REST as we are currently working on some REST engine for our backend.
This option appeared as the simplest and quickest….and I like simplicity. But simplicity is much more than a low number of LOC. In our case, the number was low thanks to the support of a REST SDK. To check about simplicity, the usage of third party should be taken into account. So, I get ride of the false argument about simplicity. The argument that the implementation is quick todo is also NEVER an…argument, this is just a fact.
Without these argument, the discussion start to be “interseting” …I erejct the idea to implement it as a REST API as REST seams not to fit at all in this picture. My argument was “this is a service, not a resource”. I get the classic “everything can be a resource, this is just a question of point of view”. You can read this excellent post from Cragg Ducan.
It does not make sense to get the collection (or list) of valid SQL, it neither makes sense to delete or put/post on a SqlValidation resource.
Then I tries to find some obvious example of service that just can’t fit into a REST paradigm. My goal was to demonstrate that REST is not “one-size-fit-all” paradigm. I can’t rely on the fact that some verbs as DELETE or PUT will not work as this is already often the case. But, I can rely on the fact that the GET is not wortking. The fundamental requirment for a GET is to be idempotent, you can call it as much as you want, you should not have any border effect (from the caller perspective) and the result should be the same. Do you see any example ? …GET http://xxx/yyy/Time which should return the current time. This is a very famous service…which can’t be deserved through a REST API.
So each time, someone tell you that REST fit all, just ask him to impelment a REST API that provide the current time…that does not fit.
I’m eprsonnaly enthousiast about REST, especially for the simplicity it brings, but it does not fit all !!