I am +1 for the Olivier's idea - and I can put my hand on fire nobody
would object it! - anyway at the same time I think Daniel's
consideration really worth - I have a past of RESTer as well :D - I
would go for
New entry: POST on ${webPath} -> returns 201 with location
Read entry: GET on ${webPath}/${key}
Update entry: PUT on ${webPath}/${key}
Delete entry: DELETE on ${webPath}/${key}
moreover I'd suggest to avoid managing the stored content in textual
format (it has a cost!), I would proceed for a pure HTTP Content-Type
negotiation:
application/x-java-serialized-object ->
org.apache.directmemory.serialization.StandardSerializer
application/x-protobuf ->
org.apache.directmemory.serialization.protobuf.ProtobufSerializer
...
and so on, no real need to jsonize requests/objects, just pure, simple HTTP.
+1 for the UI part - actual Archiva UI shows the potentials!
HTH, all the best,
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Sun, Feb 19, 2012 at 8:53 PM, Daniel Manzke
<[email protected]> wrote:
> Hi,
>
> I could start a REST war now, but I try to be normal. ;)
>
> /{webapp}/directMemory/...
>
> 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.
>
> PUT/POST/DELETE
>
> 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.
>
>
> Bye,.
> Daniel
> 2012/2/19 Olivier Lamy <[email protected]>
>
>> 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: http://coders.talend.com
>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>
>>
>> PS: FYI, Benoit has proposed a talk with myself to devoxxfr
>> (http://devoxx.fr/) and it has been accepted (wOOT really cool :-) ).
>> We hope to see you there :-).
>>
>
>
>
> --
> Viele Grüße/Best Regards
>
> Daniel Manzke
