On Mon, Apr 9, 2012 at 5:14 PM, Justin Santa Barbara
<justin@xxxxxxxxxxxx <mailto:justin@xxxxxxxxxxxx>> wrote:
When you're designing JSON considering only JSON, you'd
probably use {
key1: value1 } - as you have done. If you're designing
generically,
you'd probably use { key: key1, value: value1 }.
You mean we'd have to do dumb crap because XML doesn't have the
native concept of a list? ;)
XML has lists, as does Avro, ProtocolBuffers & Thrift. XML supports
extensible lists, which is why the syntax is different.
You'd *think* this would work. In practice, however, it
really doesn't. Neither does (good, valid) code generation...
Of course it works! Every JAX-RS webserver does this. You just
can't start with JSON first and expect everything to magically be OK.
If you think it doesn't work, can you provide an example?
You start with an abstract model, and then check what it looks like
in JSON, in XML, in ProtocolBuffers, in Avro, in Thrift, in HPSTR,
etc... If you start with JSON, then of course it won't work. If
we're going to treat XML as an afterthought, then I'd rather we just
didn't support XML at all (and yes, I absolutely mean that - it is
good that Glance is honest that they don't support XML.)
Kevin Dangoor and Christophe de Vienne have done some work on
abstracting the view of data inside and outside of the API with
TGWebServices [1] (a TurboGears add-on) and the more recent "Web
Services Made Easy" [2], which is framework agnostic. I have used TGWS
in the past to create an API using SOAP and JSON (it also supports
generic XML, but we didn't need that). I found that it worked well for
our purposes at the time.
[1] http://code.google.com/p/tgws/
[2] http://packages.python.org/WSME/