Exactly how would the below use-case be solved with REST? The incompatibilities between clients are because there is no universal way of mapping keys->server, most clients do it a little bit differently, and there is no universal list of how the flags attributes should be used, and there is no cross-platform serialization strategy.
None of those problems would be solved by REST. They're all outside the communication between a single client and a single server, and instead have everything to do with how a client handles a cluster of servers, and what a client does with the bytestreams that are actually stored in the servers. /Henrik On Thu, Jul 29, 2010 at 10:48, j.s. mammen <[email protected]> wrote: > 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. >
