Why is squid good for REST architectures?

In this article, it is argued that Use Memcach开发者_如何学Goe if you frequently fetch random entities from a database, and Squid if you use a REST architecture. Please explain why (with regard to Squid).

Memcache is a distributed object store - it's up to you to put objects in and out of this. It's a general purpose cache for any usage.

Squid is a proxy server and a web cache. If everything is through a URL (e.g. REST) then Squid will do the job for free.

So in summary, memcache is general purpose, Squid is for caching the results of a URL.

REST is all about http and resources.

squid can be used as a reverse proxy, so it will take load from the webserver. the server side can set some expires http header to indicate the timewindow for caching.

this said, the caching is done mainly over standard http headers, therefore its closer to rest styles architecture than caching db queries.

Squid (being a proxy & cache) can effectively be used with REST end-points. In REST, the resources are (supposed to) to be explicitly transferred with ETAG/Last-Modified headers in order to facilitate caching.

Furthermore, many operations in REST are (supposed to) be idempotent (repeat without further side-effects): that's a perfect situation for Squid. It can act alone on these operations without bothering the application server.

Rest uses the http verbs for their correct actions, i.e. GET is always non-destructive. Urls are also consistantly named. This means http caching in Squid can be used for performance benefit without relying on the underlying programming technology (ASP MVC, Rails, CouchDB, etc.)

(This answer comes a decade after the the initial question - but given I encounter this question in the larger organizations I consult for, I thought it useful to explain here.)

As Roy Fielding looked at SOAP, he realized that if the HTTP Methods (GET, POST, etc.) were used to access and modify resources rather than only using HTTP for mere remote procedure calls, then the rest of the HTTP specifications, such as caching (RFC-2616), could be leveraged. Fielding's layered architecture illustrates this. This is why he devised REST.

As an HTTP Caching Proxy, Squid is that implementation that can significantly reduce the load on your backend systems while also making sure that cached data is current.

The standard allows for defining how long an item can be cached before it's revalidated, and how to make conditional requests, so only new versions are sent in response to a request. All of this client behavior is already implemented in browsers and in HTTP clients used in major languages, such as Java's Apache HttpComponents Client and accompanying caching library.

Since all of these mechanisms have been clearly defined and implemented by now, making use of this is really just a matter of using these components, most of which you may already be using (e.g. as of this writing, Apache HC Components is the default implementation that comes with SpringBoot - just add the caching library into the build).

If you were to implement this using MemCache or Redis, you're simply reinventing the wheel and will have the recurring burden of having to maintain that custom code from then on. And if you don't implement the equivalent of RFC 2616 in code, you'll be using out of date data with inefficient communication.