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. 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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

On 24 April 2017 at 09:27, Sebastian Laskawiec <slaskawi(a)redhat.com&gt; 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... > [2] > https://github.com/infinispan/infinispan/blob/master/server/rest/src/test... > [3] Note that the input param here is byte[] > https://github.com/infinispan/infinispan/blob/master/server/rest/src/main... > -- > > SEBASTIAN ŁASKAWIEC > > INFINISPAN DEVELOPER > > Red Hat EMEA <https://www.redhat.com/> > <https://red.ht/sig> > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev > _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev