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

Re: [json] Glad to be here, some questions?

Expand Messages
  • 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 1 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 2 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 3 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 4 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.