Loading ...
Sorry, an error occurred while loading the content.

Glad to be here, some questions?

Expand Messages
  • gearond@sbcglobal.net
    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
        Message 3 of 5 , Jul 21, 2009
        • 0 Attachment
          On Tue, Jul 21, 2009 at 10:03 AM, Kris Zyp<kriszyp@...> wrote:
          > gearond@... wrote:
          >> (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)

          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 cross-domain requests from the browser. See:

          http://www.w3.org/TR/access-control/#simple-method

          Following the RFC will cost you an additional network round-trip for
          every unique URL in your application.

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

          I recommend using the web_send library
          <http://waterken.sf.net/web_send> for generating your JSON requests.
          It already handles things like the Content-Type for you.

          --Tyler

          --
          "Waterken News: Capability security on the Web"
          http://waterken.sourceforge.net/recent.html
        • Kris Zyp
          ... Yikes, recommending inaccurate media types? This easily leads down the hideous road of content sniffing. Hopefully that wouldn t be suggested for
          Message 4 of 5 , Jul 21, 2009
          • 0 Attachment
            Tyler Close wrote:
            > On Tue, Jul 21, 2009 at 10:03 AM, Kris Zyp<kriszyp@...
            > <mailto:kriszyp%40gmail.com>> wrote:
            > > gearond@... <mailto:gearond%40sbcglobal.net> wrote:
            > >> (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)
            >
            > 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 cross-domain requests from the browser. See:
            >
            > http://www.w3.org/TR/access-control/#simple-method
            > <http://www.w3.org/TR/access-control/#simple-method>
            >
            > Following the RFC will cost you an additional network round-trip for
            > every unique URL in your application.
            >
            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.