[infinispan-dev] REST server, dealing with Serializable

[Sebastian Laskawiec]

Ok, understood. The bottom line is - yes, we need to support Serializable.

Thanks for clarification!
Sebastian

On Mon, Apr 24, 2017 at 11:38 AM Sanne Grinovero <sanne at infinispan.org>
wrote:

> On 24 April 2017 at 09:27, Sebastian Laskawiec <slaskawi at redhat.com>
> wrote:
>
>> Hey Guys!
>>
>> I'm currently reworking REST interface and I'm scratching my head looking
>> how we deal with Serializable [1][2].
>>
>> The scenario assumes that server knows that cache stores a Serializable
>> instance and moreover, it knows how to deserialize it (and convert it to
>> XML/JSON, but that's the trivial part). I might be wrong, but I think both
>> assumptions are questionable if not wrong. At first, how to distinguish a
>> serialized instance of a class the server received [3] from a standard byte
>> array? I can imagine someone using "Content-type:
>> application/x-java-serialized-object" but it's very error prone. It also
>> leads to the question number two - how the server will know that type of
>> instance it is? This knowledge is essential for deserialization.
>>
>> I think the serialization/deserialization should be really done on the
>> client side (but as I mentioned before, maybe I don't see some important
>> use cases). I would like to remove it from refactored REST server.
>>
>
> ​To answer this specific question: the server needs to be able to
> serialize / deserialize the objects for many reasons.
> Among these we have:
>  - compatibility mode
>  - "transcoding" among different clients expecting different types
>  - indexless queries (read and compare specific fields)
>  - indexed queries (index specific fields)
>  - firing events​ (on anything more useful else than "blob was changed")
>  - avoid losing the data when encoding schemes are updated (e.g. an
> Infinispan update which includes improvements / fixes on the serialized
> representation )
>
> It's probably not an exhaustive list as I didn't follow this subject
> closely, but I guess there are enough reasons there to clarify why just
> encoding/decoding at the client side is not good enough.
>
> Thanks,
> Sanne
>
>
>
>
>>
>> What do you think?
>>
>> Thanks,
>> Sebastian
>>
>> [1]
>> https://github.com/infinispan/infinispan/blob/master/server/rest/src/main/java/org/infinispan/rest/Server.java#L267-L313
>> [2]
>> https://github.com/infinispan/infinispan/blob/master/server/rest/src/test/java/org/infinispan/rest/IntegrationTest.java#L636-L639
>> [3] Note that the input param here is byte[]
>> https://github.com/infinispan/infinispan/blob/master/server/rest/src/main/java/org/infinispan/rest/Server.java#L458
>> --
>>
>> SEBASTIAN ŁASKAWIEC
>>
>> INFINISPAN DEVELOPER
>>
>> Red Hat EMEA <https://www.redhat.com/>
>> <https://red.ht/sig>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

-- 

SEBASTIAN ŁASKAWIEC

INFINISPAN DEVELOPER

Red Hat EMEA <https://www.redhat.com/>
<https://red.ht/sig>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20170425/b67092af/attachment.html