Significant guidance needs to be given in the area of what actually constitutes RESTful design and Resource-Oriented Architecture (ROA). I am reading the book RESTful Web Services by Leonard Richardson and Sam Ruby and it has been a delightful read – it’s a great book. However, in order to explain concepts, simple examples are leveraged and this creates more questions than answers for someone want to use REST in non-CRUD like situations.
Part of the failure of the so-called “RPC web service” was the simple fact that developers were not educated correctly and hence used technologies that were available to them in the worst way possible. If care is not taken, a plethora of services that do not conform to RESTful principles will be created.
There is another side to this story however – the consumer of REST. Educating consumers on how services should be consumed RESTfully is equally as challenging. A lot of times they don’t care, they just want the job done. Stefan Tilkov posts here:
you’d have to make it three steps, which doesn’t seem a big deal from my point of view, and would ensure that you could do the DELETEs and PUTs idempotently.
Yes, you can do the DELETE and PUT idempotently but does the consumer really care about this puristic application of REST? Are we positive that the consumer will not argue that they should be able to send in a “batch” in one shot for performance reasons (or because their legacy service worked that way?). Half the battle is building the service RESTfully, the other half is getting people to consume it the way YOU (or me) believe it should be consumed. Both are difficult challenges.