HTTP caching and REST of us.

    Imagine you want to create a web service to query some of your domain objects.
Definitely this can be done with SOAP over HTTP.

POST /person HTTP/1.1







If there appears that your application is under heavy load and has many customers it can happen that your application can not handle it. Ofcourse it is very dependent on the design you are using, other techniqeus you are using like second level cache like EhCache or maybe you are using NoSql or mixed solution . Here I will isolate all this points and will focus just on a http path botleneck. This botleneck can be solved by using a caching reverse proxy. BUT!!!
imagine we need to cache the result of the above mentioned query. The proxy needs to check if the HTTP request is a SOAP request and the and then check if it contains the personQuery operation. If it finds this one extract the personId and use it as a key in it's own cache. It appears that this proxy is completely unique and made for specific operation if you change the name of the operation or the ID field or add another operation you will have to change the proxy. In order to use generic proxy all od the operations need to have additional metta information like if they are read-only and what are
their target objects.

Method: READ
Target: example.com/person/1234

Actually this is very similar to standard HTTP operations  which would look like

GET  /person/1234
Host example.com

It is not a coincidence that HTTP operations are designed for such a great scalability. If you represent web service operations as one of the HTTP verbs you will use this scalability if
you configure properly HTTP reverce proxy.
I have been using these design not only for HTTP but also with ICE (Intenet communication engine) from ZeroC. ICE is modern RPC style midleware similar to CORBA but much more sophisticated
and efficient. Usually you need midleware like ICE if you need fast, scalable, low latency  communication with very low memmory footprint. What we have created is a REST style facades and expressed all of the CRUD
operations on a objects trough those BaseFacades. The base facades contains operations similar to the HTTP methods. This way we achieved scalability, caching and flexibility of the midleware
intermediate components. In the next topics I will present how we have using Varnish (HTTP master piece reverse proxy with caching and load balancing capabilities and many more) to achieve scalable
REST services.