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.
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
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:
+----+
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)
Thanks for brainstorming!
-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
