Salut! > BTW nothing prevent to have both implementations (based on > Content-Type "application/json;charset=UTF-8" for json model exchange > :-) )
sure, that is why I like content type negotiation: same URI, different way to exchange content. Simple & cool at the same time :P > Doh sure we can "win" some packet on network layer :-) > lol, aren't we problem solvers? :D > Ok I will start as it. My first impl (push) will be with json exchange > as I have it locally :-). > > Then I will improve with the "raw" model based on Content-Type and http > headers. looking forward to read the code, hope to be helpful! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Mon, Feb 20, 2012 at 11:01 AM, Olivier Lamy <[email protected]> wrote: > 2012/2/20 Simone Tripodi <[email protected]>: >> Salut! >> >> I see we have 2 different use cases in mind, that is why we are not in sync. >> >> I personally see that adopting your APIs layer, for each request, body >> content has to be serialized in a textual form - no matter how fast it >> is, that means that both client/server need to (de)serialize the >> content. > >> >> The client builds the request -> serialize it in JSON -> creates the >> JSON request -> send it to the server -> the server extract the JSON >> content -> stream it in the memory. > agree it can be a performance "problem". > > >> >> Let's explore more possibilities: you can still map your JSON request >> model to pure HTTP protocol: >> >> {"DirectMemoryRQ":{"key":"101","expiresIn":123,"cacheContent":"*here a >> json/xml string* >> ","serializer":"org.apache.directmemory.serialization.StandardSerializer"}} >> >> would become >> >> +----+ >> PUT ${webPath}/${key} >> Content-Type: text/xml > I would prefer use an other Content-Type IMHO > "application/x-java-serialized-object" was a good idea. >> Expires: Thu, 01 Dec 2012 16:00:00 GMT >> >> serialized-body >> +----+ >> >> extra non-standard fields can be added via the X- prefix, for example, >> the preference of used serializer to store the content: > Good idea. >> >> +----+ >> PUT ${webPath}/${key} >> Content-Type: text/xml >> Expires: Thu, 01 Dec 2012 16:00:00 GMT >> X-DirectMemory-Serializer: >> org.apache.directmemory.serialization.StandardSerializer >> >> serialized-body >> +----+ >> >> You should still be able to write the JS httpclient to interact with >> the server - it is just HTTP! - without paying the overhead of more >> parsing operations. >> >> Moreover, if you'll proceed to JSON, I think that the proposed format >> can be thiner: >> >> {"DirectMemoryRQ":{"key":"101","expiresIn":123,"cacheContent":"*here a >> json/xml string* >> ","serializer":"org.apache.directmemory.serialization.StandardSerializer"}} >> >> could be >> >> {"key":"101","expiresIn":123,"cacheContent":"*here a >> json/xml string* >> ","serializer":"org.apache.directmemory.serialization.StandardSerializer"} >> >> dropping the DirectMemoryRQ container (it is yet another data structure :P) > > Doh sure we can "win" some packet on network layer :-) > > Ok I will start as it. My first impl (push) will be with json exchange > as I have it locally :-). > > Then I will improve with the "raw" model based on Content-Type and http > headers. > >> >> Thanks for brainstorming! > > You're welcome :P > >> -Simo >> >> http://people.apache.org/~simonetripodi/ >> http://simonetripodi.livejournal.com/ >> http://twitter.com/simonetripodi >> http://www.99soft.org/ >> >> >> >> On Mon, Feb 20, 2012 at 9:55 AM, Olivier Lamy <[email protected]> wrote: >>> Hello, >>> >>> 2012/2/20 Simone Tripodi <[email protected]>: >>>>> Hmmmm. Simone should answer this. >>>>> >>>>> If I'm really thinking about it, the content-type makes no sense. ;) >>>> >>>> it does instead, because the server has to be able to reply the >>>> serialization content type when clients ask for stored - or you expect >>>> the client automagically understands it? Or you expect to have just >>>> one client type per application, so the serialization type is always >>>> the same? Couldn't servers be populated by heterogeneous clients that >>>> read each other data? >>> The client will be responsible for de/serialization. >>> My preference for more "complex" content is for new feature and >>> enhance cache request/response with new field. >>> >>> retrieve object : >>> GET on ${webPath}/cache/${key} >>> >>> return json content if found >>> >>> {"DirectMemoryRS":{"key":"101","cacheContent":"Zm9vIGJhcg=="}} >>> Using this format we will be able to add new fields in the ison >>> "object" (cacheAge etc...) >>> >>> PUT on ${webPath}/cache >>> >>> json content posted >>> >>> {"DirectMemoryRQ":{"key":"101","expiresIn":123,"cacheContent":"rO0ABXNyACtvcmcuYXBhY2hlLmRpcmVjdG1lbW9yeS5zZXJ2ZXIuY29tbW9ucy5XaW5l5dYKhxyAjeECAAFMAARuYW1ldAASTGphdmEvbGFuZy9TdHJpbmc7eHB0AAhCb3JkZWF1eA==","serializer":"org.apache.directmemory.serialization.StandardSerializer"}} >>> >>> Again using a json "object" we will be able to easily add new "fields". >>> >>> Why using json I have in mind using cache access directly tru a >>> javascript application with something like : >>> >>> {"DirectMemoryRQ":{"key":"101","expiresIn":123,"cacheContent":"*here a >>> json/xml string* >>> ","serializer":"org.apache.directmemory.serialization.StandardSerializer"}} >>> >>> As it the server we will be able to serialize then store the json/xml >>> content. >>> And you can use directly from your javascript application. >>> >>> Compare to an Api. >>> >>> wineService.findWine(year, name) >>> >>> wineService.find(wineSearchRequest) >>> >>> With >>> WineSearchRequest { >>> year; >>> name; >>> } >>> >>> I tend to prefer using the second pattern as it's more easy to improve >>> the model without breaking (normally :-) ) the backward comp. >>> >>> Makes sense ? >>> >>>> >>>> "makes no sense" is a hard assertion, I always think more than twice >>>> before saying that ;) >>>> >>>> http://people.apache.org/~simonetripodi/ >>>> http://simonetripodi.livejournal.com/ >>>> http://twitter.com/simonetripodi >>>> http://www.99soft.org/ >>> >>> >>> >>> -- >>> Olivier Lamy >>> Talend: http://coders.talend.com >>> http://twitter.com/olamy | http://linkedin.com/in/olamy > > > > -- > Olivier Lamy > Talend: http://coders.talend.com > http://twitter.com/olamy | http://linkedin.com/in/olamy
