Here is an example use case found in Memcached WIKI. I think the below usecase could benefit from REST ==== Example use-case¶
My company Widgets&Sprockets has a distributed SOA architecture that uses a brokerage object for distributing web service traffic across several hundred services. Large portions of the respones to this traffic can be cached in the brokerage object (they are just xml documents stored as UTF8 encoded strings). These requests are optomised by first checking the cache before even hitting the brokerage object, sadly however the company has a legacy architecture leading to some of the calls being sent to the brokerage object coming from Java and some from C#. Currently it is not a trivial task to retrieve the XML documents from the cache from both Java & C# without some heavy patching. The two clients chosen for this use-case are the excellent C# memcached client library Enyim.Memcached and the fabulous Java memcached client library Spy.Net. Please note this code is not curently possible on the C# side as several patches are pending being applied to the client (it is entirely possible that they won't be applied, so this may remain a proof-of-concept rather than a true example implementation) ===== On Jul 29, 8:42 am, jsm <[email protected]> wrote: > What I meant was to add a REST protocol to memcached layer, just like > you have a binary protocol and ascii. > Its up to the user to decide which protocol to use when accessing > memcached objects. > Regards, > J.S.Mammen > > On Jul 29, 1:49 am, Aaron Stone <[email protected]> wrote: > > > > > 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.
