On Wed, Jul 28, 2010 at 8:37 AM, jsm <[email protected]> wrote: > > > On Jul 28, 8:02 pm, Rajesh Nair <[email protected]> wrote: >> Gavin, >> >> If you go by the strict sense of word, HTTP protocol is not a pre-requisite >> for REST service. >> It requires a protocol which supports linking entities through URIs. It is >> very much possible to implement a RESTful service by coming up with own URI >> protocol for memcached messages >> >> something like : >> mc://<memcached-cluster>/messages/<key> >> >> and the transport layer can be pretty much the same TCP to not add any >> overhead. >> >> JSM, >> >> What is the value-add you are looking from the RESTful version of the >> memcached API? > > Basically to be able to use without binding to any particular > language.
I read this as requesting memcached native support for structured values (e.g. hashes, lists, etc.) -- is that what you meant? Aaron >> >> Regards, >> Rajesh Nair >> >> On Wed, Jul 28, 2010 at 8:13 PM, Gavin M. Roy <[email protected]> wrote: >> >> >> >> > Why add the HTTP protocol overhead? REST/HTTP would add ~75Mbps of >> > additional traffic at 100k gets per second by saying there's a rough 100 >> > byte overhead per request over the ASCII protocol. I base the 100 bytes by >> > the HTTP GET request, minimal request headers and minimal response >> > headers. The binary protocol is very terse in comparison to the ASCII >> > protocol. In addition netcat or telnet works as good as curl for drop dead >> > simplicity. Don't get me wrong, it would be neat, but shouldn't be >> > considered in moderately well used memcached environments. >> >> > Regards, >> >> > Gavin >> >> > On Wed, Jul 28, 2010 at 8:43 AM, jsm <[email protected]> wrote: >> >> >> Anyone writing or planning to write a REST API for memcached? >> >> If no such plan, I would be interested in writing a REST API. >> >> Any suggestions, comments welcome.
