Agree on suggestion and the raw servlet model. BTW I don't follow/understand you regarding the Content-Type. It's just to say the serializer used ? Because Object to cache must be serialized on client side before going to the server.
2012/2/19 Daniel Manzke <[email protected]>: > (after another long discussion with simone ;)) > > +1 for the content-type idea. I think there should be a server-side > configuration, where you can map content-type to serializers. > > Like mentioned before, I would add a cache "layer" in the path, so you can > add new caches at runtime. (necessary for cloud env? :)) Why not even if the goal was not really to have more than direct memory impl on server side :-) > > BTW: What comes after the cloud? The sky! :P > > New/update entry: PUT on ${webPath}/${key} -> body has the object which > should be serialized > Contains entry: HEAD on ${webPath}/${key} -> 200 / 404 > Read entry: GET on ${webPath}/${key} > Delete entry: DELETE on ${webPath}/${key} > > Bye, > Daniel > > 2012/2/19 Simone Tripodi <[email protected]> > >> 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"? ${contextPath}/cache/etc... ? Yup separation will be needed for ui part. I will try to push some code early this week. >> > >> > 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 >> > > > > -- > Viele Grüße/Best Regards > > Daniel Manzke -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy
