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

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

Expand Messages
  • 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 1 of 5 , Jul 21 2:35 PM
    • 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 2 of 5 , Jul 21 3:01 PM
      • 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 3 of 5 , Jul 21 3:27 PM
        • 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.