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
