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 <lesmikes...@gmail.com>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
> lesmikes...@gmail.com
>
--
awl
