My second question of the day regarding REST JSON... sorry I am experiencing issues deserializing some REST JSON responses where the response schema changes depending on the output. I know that JSON doesn't support schemas in the .xsd sense, but I at least expect the response structure to be the same across different kinds of responses.
For example If I query the data stores within a workspace that does contain data stores the response looks like this: {"dataStores":{"dataStore":[{"name":"...","href":"..."},{"name":"...","href":"..."}]}} However if the workspace contains no data stores the response looks like this: {"dataStores":""} when I would expect it to look like this: {"dataStores":{"dataStore":[]}} This makes it impossible for me to deserialize the response into a single type (in Java). I can overload my class's dataStores setter (setDataStores) to accept both a String and a dataStore collection, but my class can only have one property called dataStores and this must be either a String or a collection. This means that I have to inspect the text of the JSON response before I attempt deserialization, which feels like a bad workaround. Is this by design? Should I submit a feature request? And can anyone convince me that this is a good idea? Thanks -- View this message in context: http://osgeo-org.1560.n6.nabble.com/Inconsistency-in-REST-JSON-responses-tp4982837.html Sent from the GeoServer - User mailing list archive at Nabble.com. ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Geoserver-users mailing list Geoserver-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-users