On Mon, May 17, 2010 at 09:45:37AM -0400, Bryan Kearney wrote:
On 05/17/2010 08:44 AM, James Bowes wrote:
>All:
>
>I've pushed out a new branch for some fiddling I did on Friday night to
>move from jettison for json reading/writing to jackson. IMO jackson
>creates much nicer json. Here's what a consumer looks like:
>
>== OLD ==
>
>{"consumer" : {
> "name" : "my consumer",
> "type" : {"label" : "system" }
> }
>}
>
>== NEW ==
>
>{"name" : "my consumer",
> "type" : "system"}
So.. type is an object.. how does it know that in this case? Since
type can have an id as well, how would that be shown?
It knows because the type field on Consumer is a ConsumerType. Jackson
appears to be smart enough that if you set "type" as a json object,
like jettison did, ie:
"type" : {"label" : "system", "id" 3}
It will call the default constructor and fill in the bean properties.
Likewise, if he had a constructor on ConsumerType that took a numeric
value, we could set
"type" : 3
And it would do the right thing. However, I don't think we want to
support all of this, just to keep the bugs down.
>
>Through nicer json, we get nicer client code (fewer redundant
>variable/key names).
>
>Another cool think about jackson is it can generate json schema, which
>I've hooked up in a few cases to the ApiCrawler.
>
>Before bringing this into master, I'd like to:
> * make sure the java client speaks new json
This may hork up clients like ruby which key off of the object name
for their auto binding. How does this json compare with the json
from Deltacloud?
I can't find any docs for their json api (seems like xml is what they
support for now), but there are annotations to have your classes add
type hints. What sucks though is that for every google hit I get for
json type hinting has a different way of doing it :(
On the java client, I am currently using the RestEasy bindings, so
it should work fine there.
> * come up with a convention for variable names in json. I'd like to do:
> endDate => end_date, as I think the underscore looks more jsonic.
> enforce this convention.
See how this jives with the rest guides stuff which Mark McGlouphlin
is puting out.
> * Create our own json reader/writer so we can configure jacksons
> settings for:
> * Use "YYYY-MM-DDTHH:MM:SS-04:00" for datetime, rather than seconds
> since the epoch
> * allow a configurable toggle for json pretty printing (great for
> debugging)
> * Have the hooks in place for input validation (do after merge)
> * Check for any concessions we made with jettison re base64 encoding or
> int to string conversion, and elimnate them.
> * consider dropping xml support, or consider using jaxb annotations for
> jackson.
I would prefer to keep XML in since it seems like "the right thing
to do". If it causes issues, I can live with dropping it.
Thanks!
-- bk
-James