1306Re: [json] Glad to be here, some questions?
- Jul 21, 2009Tyler Close wrote:
> On Tue, Jul 21, 2009 at 10:03 AM, Kris Zyp<kriszyp@...Yikes, recommending inaccurate media types? This easily leads down the
> <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:
> Following the RFC will cost you an additional network round-trip for
> every unique URL in your application.
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 :/.
>Yes, the web is awash with abuses, so it is wise to be tolerant of
> AFAICT, very few JSON services use application/json, so your code
> should be tolerant of responses with other Content-Type header values.
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).
- << Previous post in topic Next post in topic >>