REST

I have been coming up to speed on REST for the last couple of days or so. Some obvious and some not-so-obvious things I've learned:

1. REST may be the architectural style on which the World Wide Web was built, but it's not exactly tailor made for web applications (accessed by humans from browsers).
   


2. Since REST favors a stateless mode of interaction, transactions will have to be done outside REST (not even sure if this is possible), or we'll have to treat each service invocation as atomic, and build compensating transactions a la BPEL.
   


3. REST mandates that we model the application in terms of resources and representations. Not sure how well can this be mapped to the domain we are modeling. It's easy to say 'think in terms of resources, not services', but dressing up an itinerary creation service as an itinerary creator object (sorry, resource) doesn't cut it, IMHO.


4. We need an HTTP client to program to a REST service; support for PUT/DELETE in browsers is not available (yet?). Don't know whether this can be done in JavaScript.


5. If we want to architect a web application whose service layer is implemented in REST, we will need two web/application server layers -- one to receive the request from the browser client, and another that actually implements the service. The two layers can be collocated, of course.
   


6. This is a minor nit: since one of the strengths of REST is the uniform interface, there is no interface specification (equivalent of WSDL), and we cannot generate the service invocation code automatically.


7. More network traffic as we need to transport more information to the service because of its statelessness.


8. Authentication information needs to be sent with each request. This implies that the first layer in point #5 will have to manage the session data if it is servicing a user logged in from the browser application. The scalability benefits are therefore not available to this layer.


9. Issues like locking, concurrency, etc. seem tricky. I haven't thought this through yet, but off the top of my head, things like including a timestamp field in the representation seem necessary.