Glad to be here, some questions?

Hello all, I am starting an iphone app using json as the data interchange. I m still coming up to speed on the JSON specs .... and more mportantly,

Message 1 of 5
, Jul 21, 2009

0 Attachment

Hello all,
I am starting an iphone app using json as the data interchange. I"m still coming up to speed on the JSON specs .... and more mportantly, the *conventions* for how it is used.
So I would like to ask the following(surveyish, I know). If you know how some of the bigger services do it, Yahoo's, Amazon, Google, Twitter, etc, please comment on that. I'll assemble the results and post them:

(1) When sending a new record to a service, via POST, do you:
(a) append the raw JSON string below the HTTP headers, etc using
which mime type?
(b) use mime type 'application/x-www-form-urlencoded' and make
the JSON string a single name value pair,
like 'json=json_string'
(c) use mime type 'multipart/form-data', puttng the JSON payload
into its own seperated block, using what kind of mime type
for that block, and is the JSON urlencoded or raw?
(d) Do you reject any record that contains a value for an
automatically assigned field value, like an auto incrementing
primary key value?

(2) When using PUT to change a record:
Do you require all fields be submitted?
Or do you only change the ones that are present in JSON payload?

Thanks all, please send references to the reason you do something a certain way (like an RFC or other JSON/HTTP spec) if you know it.

Again, I"ll compile what I get and feed it back all in one document.

Dennis Gearon

Signature Warning
----------------
EARTH has a Right To Life

I agree with Bolivian President Evo Morales

# The right to life: "The right for no ecosystem to be eliminated by the irresponsible acts of human beings."

# The right of biosystems to regenerate themselves: "Development cannot be infinite. There's a limit on everything."

# The right to a clean life: "The right for Mother Earth to live without contamination, pollution. Fish and animals and trees have rights."

# The right to harmony and balance between everyone and everything: "We are all interdependent."

See the movie - 'Inconvenient Truth'
See the movie - 'Syriana'

Kris Zyp

The restful-json group (http://groups.google.com/group/restful-json) might actually be a better fit for these questions, more focused on JSON in a REST

Message 2 of 5
, Jul 21, 2009

0 Attachment

The restful-json group (http://groups.google.com/group/restful-json)
might actually be a better fit for these questions, more focused on JSON
in a REST architecture, but to try answer your questions...

gearond@... wrote:

> Hello all,
> I am starting an iphone app using json as the data interchange.
> I"m still coming up to speed on the JSON specs .... and more
> mportantly, the *conventions* for how it is used.
> So I would like to ask the following(surveyish
>
> , I know). If you know how some of the bigger services do it, Yahoo's,
> Amazon, Google, Twitter, etc, please comment on that. I'll assemble
> the results and post them:
>
> (1) When sending a new record to a service, via POST, do you:
> (a) append the raw JSON string below the HTTP headers, etc using
> which mime type?
>

RFC 4627 specifies application/json (and I highly recommend that you
follow that advise)

> (b) use mime type 'application/x-www-form-urlencoded' and make
> the JSON string a single name value pair,
> like 'json=json_string'
>

icky

>
> (c) use mime type 'multipart/form-data', puttng the JSON payload
> into its own seperated block, using what kind of mime type
> for that block, and is the JSON urlencoded or raw?
> (d) Do you reject any record that contains a value for an
> automatically assigned field value, like an auto incrementing
> primary key value?
>

In my project (Persevere http://www.persvr.org) primary keys can usually
be assigned by the client or server, so they aren't rejected. However,
if a (optional) schema has been specified for a table, properties values
that invalid according to the schema will cause the request to be
rejected (403).

>
> (2) When using PUT to change a record:
> Do you require all fields be submitted?
> Or do you only change the ones that are present in JSON payload?
>

By my reading of RFC 2616, all fields should be submitted because the
entity should (at least roughly) correspond to the desired
representation to be returned on a GET. A payload with only changed
fields more closely matches the semantics of a PATCH or POST request.

>
>
> Thanks all, please send references to the reason you do something a
> certain way (like an RFC or other JSON/HTTP spec) if you know it.
>
> Again, I"ll compile what I get and feed it back all in one document.
>

Another implementation of JSON HTTP/REST that might be of interest is
Dojo's JsonRestStore.

Kris

Tyler Close

... From a practical perspective, it is better to label your POST entity as Content-Type text/plain , since this will be handled more efficiently in

Yikes, recommending inaccurate media types? This easily leads down the
hideous road of content sniffing. Hopefully that wouldn't be suggested
for same-origin communication where media types can be accurately
specified. Of course when it comes to cross-domain there tons of hacks
that we have to resort to, JSONP, window.name, fragment identifiers, so
standards do indeed have to tempered with practicality. But, CS-XHR is
supposed to provide a better road, seems a shame we are already seeing
hacks laid on it :/.

>
> AFAICT, very few JSON services use application/json, so your code
> should be tolerant of responses with other Content-Type header values.
>

Yes, the web is awash with abuses, so it is wise to be tolerant of
responses, but I wouldn't recommend contributing to the mess. Dojo's
JSON HTTP/REST client (JsonRestStore) does properly set the Content-Type
to application/json for same-origin PUT and POST requests. Needless to
say that is the client I would recommend :). (of course I am biased, and
I am sure web_send is good as well, Tyler's work is excellent).

Kris

Tatu Saloranta

On Tue, Jul 21, 2009 at 3:01 PM, Kris Zyp wrote: ... I fully agree -- I would prefer using proper content/media types, since those do serve

Message 5 of 5
, Jul 21, 2009

0 Attachment

On Tue, Jul 21, 2009 at 3:01 PM, Kris Zyp<kriszyp@...> wrote:
...
>> AFAICT, very few JSON services use application/json, so your code
>> should be tolerant of responses with other Content-Type header values.
>>
> Yes, the web is awash with abuses, so it is wise to be tolerant of
> responses, but I wouldn't recommend contributing to the mess. Dojo's
> JSON HTTP/REST client (JsonRestStore) does properly set the Content-Type
> to application/json for same-origin PUT and POST requests. Needless to
> say that is the client I would recommend :). (of course I am biased, and
> I am sure web_send is good as well, Tyler's work is excellent).

I fully agree -- I would prefer using proper content/media types,
since those do serve purpose esp. regarding intermediaries.

Another thing to consider is that JSON is hardly only sent by
browsers: most of my own use cases are for services communicating (or
in general non-browser clients). So it is not reasonable to assume
that most decisions be driven by what browsers do -- yes, JSON is
convenient for that use case, but applicability extends well beyond
that domain.

-+ Tatu +-

Your message has been successfully submitted and would be delivered to recipients shortly.