On Mon, May 17, 2010 at 09:22:03AM -0400, Jesus M. Rodriguez wrote:
On Mon, May 17, 2010 at 8:44 AM, James Bowes
<jbowes(a)redhat.com> 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"}
>
How does it handle lists and child objects? For example does a list appear with
a name:
{"name":"my consumer",
"owners":[{"name":"foo"},
{"name":"bar"}]
}
OR without a name:
{"name":"my consumer",
[{"name":"foo"}, {"name":"bar"}]
}
It has a name.
I forgot to mention what the facts look like on a consumer, which is my
favorite part.
OLD - "facts" : {{"key" : "cpu", "value" :
"i386"}, ...
NEW - "facts" : {"cpu" : "i386", ...
> 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
> * 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.
+1 to _ :)
> * 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
+1 we want to stick with the standard ISO8601 format.
> * allow a configurable toggle for json pretty printing (great for
> debugging)
+1
> * 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.
That was my next question, what happens to XML support. Today we have
the option of supporting both XML and JSON simply based on the client's
accept header. But to be honest I don't think we have even tested the XML
at all. Plus there are many REST apis which only support JSON.
I'm ok with dropping XML support.
Yeah, same here. My main concern is keeping the API stable, which means
we have to pay attention to the output of every mime type we support.
> I've also got patches for the python code locally, for when
we switch.
>
> Comments?
Did you figure out the object graph serialization problem with jackson? the
one where it just starts going down the entire graph. /me assumes you did
but never hurts to ask :D
Yeah, I did. I had to put @JsonIgnore everywhere we have @XmlTransient.
If we are able to configure jackson directly, we can tell it to use jaxb
annotations, which I suggest we do if we want to continue support of
xml. Actually, you can use both styles of annotations, and declare
precedence, too. Pretty good stuff.
Great work! Thanks for diving into this.
My pleasure :)
jesus
_______________________________________________
candlepin mailing list
candlepin(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/candlepin
-James