There's no argument that embedding a locally-configured memcache client
library for the appropriate language into your program would be more
efficient, but consider the case where you have many programs in many
languages sharing the cache data and some of them have inherent http
capability and aren't used enough to care about that last 10% efficiency
when it means rewriting a bunch of code with new libraries to get it.
However, I still think the http interface would have to be a separate
standalone piece, sitting over a stock client that knows about the local
distributed servers or you'd need a special client library anyway.
-Les
On 7/28/2010 12:53 PM, Adam Lee wrote:
memcached's protocol is, as has been pointed out, already language
agnostic and much more efficient than trying to do HTTP. If you're
saying RESTful in the "not necessarily HTTP" sense, though, then I'd say
that memcached's text protocol is basically already as RESTful as you're
going to get- think of commands as verbs ('get,' 'set,' 'add,' 'delete,'
etc...) and the key as a URI and you're basically in an analogous
situation that I think basically meets the criteria as much as you can
(hard to have a stateless cache)...
http://en.wikipedia.org/wiki/Representational_State_Transfer#Constraints
If you want a key-value datastore with an HTTP interface, though, might
I recommend Tokyo Tyrant? It speaks memcached and its own binary
protocol as well: http://1978th.net/tokyotyrant/spex.html#protocol
On Wed, Jul 28, 2010 at 12:03 PM, Les Mikesell <[email protected]
<mailto:[email protected]>> wrote:
On 7/28/2010 10:16 AM, jsm wrote:
Gavin,
You are right about the overhead and also saw that API's exist for
most of the languages as well.
I thought REST API would make memcached language agnostic.
I would like to hear from the community if the REST API should be
pursued or not?
I'm not quite sure how a rest api could deal with the distributed
servers without a special client anyway. But, it might be handy to
have a web service that mapped a rest api as directly as possible to
memcache operations where the http side would use traditional load
balance/fail over methods and handle the http 1.1 connection
caching. I'm sure there would be places where this could be used by
components that have/want data in a cache shared by more efficient
clients.
--
Les Mikesell
[email protected] <mailto:[email protected]>
--
awl
