incubator-directmemory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Manzke <>
Subject Re: [DISCUSS] RFC Server implementation
Date Sun, 19 Feb 2012 19:53:05 GMT

I could start a REST war now, but I try to be normal. ;)


Why do you need "directMemory"? Are there any other implementations?
"directMemory" can be the webapp name, if you need it, but you should not
use it there.

Why do you need "/store" to simulate methods? You have all you need in http.


And you are already using it. ;)

I would do it like this:

New entry: PUT on ${webPath} -> returns 201 with location
Read entry: GET on ${webPath}/${key}
Update entry: PUT/POST on ${webPath}/${key}
Delete entry: DELETE on ${webPath}/${key}

If you want some kind of separation because of having a website or
something else a name for the resource would be fine. (but I wouldn't call
it directMemory) Maybe "store" or "cache"?

Additionally I would add a name for the cache to the api.
GET on ${webPath}/${cache}/${key}

So you could have multiple caches for different scenarios.

2012/2/19 Olivier Lamy <>

> Hello Folks,
> I have started to think/hack around having a server implementation to
> store object in a direct memory cache (something "à la" memcached).
> Before discussing about api (fluent or not) having ugly names for
> methods or not ( :P ).
> I'd like to share with you my ideas (and get your feedback).
> Basically I have something in mind to ease users life:
> * retrieve this object with this key (sync and async methods)
> * store this object with this key and with this serializer. (sync and
> async methods)
> * delete an entry (sync and async methods)
> The de/serialization is done on client side and exchange are done tru
> REST (json) over http(s). (Maybe adding later too a "raw" servlet with
> parameters passed as headers)
> REST Api ideas.
> retrieve object :
> GET on ${webPath}/directMemory/retrieve/${key}
> return json content if found
> {"DirectMemoryRS":{"key":"101","cacheContent":"Zm9vIGJhcg=="}}
> cacheContent is byte[] from serialization.
> If no cache entry found for the key, http code returned will be 204
> (No Content) but client api will receive a DirectMemoryCacheResponse
> object with found field to false.
> store object
> PUT on ${webPath}/directMemory/store
> json content posted
> {"DirectMemoryRQ":{"key":"101","expiresIn":123,"cacheContent":"rO0ABXNyACtvcmcuYXBhY2hlLmRpcmVjdG1lbW9yeS5zZXJ2ZXIuY29tbW9ucy5XaW5l5dYKhxyAjeECAAFMAARuYW1ldAASTGphdmEvbGFuZy9TdHJpbmc7eHB0AAhCb3JkZWF1eA==","serializer":"org.apache.directmemory.serialization.StandardSerializer"}}
> (serializer is for information and if available on server classLoader
> could be use for a toString in the web ui).
> delete an entry:
> DELETE on ${webPath}/directMemory/delete/${key}
> 200 if ok, 204 if the key was not found.
> Goodies: the webapp will have an ui to display some figures on cache
> hit ratio, number of stored elements etc...
> Let me know if that makes sense and I can start push some hack :-)
> --
> Olivier Lamy
> Talend:
> |
> PS: FYI, Benoit has proposed a talk with myself to devoxxfr
> ( and it has been accepted (wOOT really cool :-) ).
> We hope to see you there :-).

Viele Grüße/Best Regards

Daniel Manzke

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message