On Mon, Apr 9, 2012 at 5:14 PM, Justin Santa Barbara <jus...@fathomdb.com>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/
_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
