3 ms·

>Should add some header to say that it's JSON, or add a .json file extension for the main page data. The server sends `Content-Type: application/json` and prov

by pilif 11y ago

>Should add some header to say that it's JSON, or add a .json file extension for the main page data. The server sends `Content-Type: application/json` and provides no header related to caching. Browsers that do anything but fetching the resource again are not spec compliant. Also, the only browser to ever look at the extension of a file in the URL was IE (https://msdn.microsoft.com/en-us/library/ms775147(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/ms775147(v=vs.85).a...) and they have long since stopped doing that as all it was doing was cause security issues and screw with web developers.

msane 11y ago
Correct answer. The demo is doing everything right, parent seems confused. Browsers also don't have any special regard for '.json' in the path. The path can be anything; the path doesn't suggest anything about content-type or caching.
- JoshTriplett 11y ago
  > Browsers also don't have any special regard for '.json' in the path. Browsers shouldn't care about file extensions, ever, but some versions of IE did.
- wisty 11y ago
  Yes, but if / returns a html file, and /.json returns the json, it's impossible for a browser to display the json by accident (no matter what the header is). And yes, the header seems correct, Checking, that's the API demo, the GUI is separate. Thus the confusion. Yeah, headers are the right way to do it, but a different path is also the right way to do it, and extensions like .json can make that simpler in some cases. Or /api/ prefixes.
  - dijit 11y ago
    / being an index which points to a .html file is completely arbitrary though. there's no specification that says it must be so.
  - CHY872 11y ago
    No. The browser should send with its HTTP request: Accept: text/html, application/json;q=0.8 and then if the server supports returning HTML, it should return it ahead of any json. For example, Firefox sends: Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 and then it will send HTML ahead of xml, ahead of anything else, where it can. If a RESTful client can only accept JSON, it should send Accept: application/json Headers are the right way to do it with a RESTful API. The reason why is that the path should indicate the resource you're trying to access and the resource is independent of the data format. Adding '.json', path specifiers etc is a kludge; it requires web server support to actually work properly (it requires the webserver to send the right MIMEtype in the header). The browsers ignore it (I think). For example, occasionally you'll click on an image (I see it about once a year) and you get back a stream of weird unicode. This is because the webserver is returning the .jpg as text/html or whatever, and the browser is rendering it as such. Likewise, when you go on https://raw.githubusercontent.com/resume/resume.github.com/master/index.html https://raw.githubusercontent.com/resume/resume.github.com/m... you are presented with plaintext because it has returned as Content-type: text/plain, even though the data is actually HTML.
aidos 11y ago
Thanks for the flashback! I'd forgotten about the days when we used to add something like &ft=.pdf to the end of querystrings so IE would recognise the file as PDF. I can't remember the other tricks, but there was a whole raft of things you'd do to force downloading of content, or not.
markbernard 11y ago
Are you sure about that? Cache-Control, Expires? If you don't change the URL IE will cache the response whether you like it or not. 2 ways to handle this are to generate a random number to append as a parameter to change the URL. The other way is to have your web service to tell the browser not to cache with response headers. I have had IE do this to me and made all my web services send back "Cache-Control: no-cache" to prevent IE caching.

by pilif 11y ago

msane 11y ago

Correct answer. The demo is doing everything right, parent seems confused. Browsers also don't have any special regard for '.json' in the path. The path can be anything; the path doesn't suggest anything about content-type or caching.

JoshTriplett 11y ago
> Browsers also don't have any special regard for '.json' in the path. Browsers shouldn't care about file extensions, ever, but some versions of IE did.
wisty 11y ago
Yes, but if / returns a html file, and /.json returns the json, it's impossible for a browser to display the json by accident (no matter what the header is). And yes, the header seems correct, Checking, that's the API demo, the GUI is separate. Thus the confusion. Yeah, headers are the right way to do it, but a different path is also the right way to do it, and extensions like .json can make that simpler in some cases. Or /api/ prefixes.
- dijit 11y ago
  / being an index which points to a .html file is completely arbitrary though. there's no specification that says it must be so.
- CHY872 11y ago
  No. The browser should send with its HTTP request: Accept: text/html, application/json;q=0.8 and then if the server supports returning HTML, it should return it ahead of any json. For example, Firefox sends: Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 and then it will send HTML ahead of xml, ahead of anything else, where it can. If a RESTful client can only accept JSON, it should send Accept: application/json Headers are the right way to do it with a RESTful API. The reason why is that the path should indicate the resource you're trying to access and the resource is independent of the data format. Adding '.json', path specifiers etc is a kludge; it requires web server support to actually work properly (it requires the webserver to send the right MIMEtype in the header). The browsers ignore it (I think). For example, occasionally you'll click on an image (I see it about once a year) and you get back a stream of weird unicode. This is because the webserver is returning the .jpg as text/html or whatever, and the browser is rendering it as such. Likewise, when you go on https://raw.githubusercontent.com/resume/resume.github.com/master/index.html https://raw.githubusercontent.com/resume/resume.github.com/m... you are presented with plaintext because it has returned as Content-type: text/plain, even though the data is actually HTML.

aidos 11y ago

Thanks for the flashback! I'd forgotten about the days when we used to add something like &ft=.pdf to the end of querystrings so IE would recognise the file as PDF. I can't remember the other tricks, but there was a whole raft of things you'd do to force downloading of content, or not.

markbernard 11y ago

Are you sure about that? Cache-Control, Expires? If you don't change the URL IE will cache the response whether you like it or not. 2 ways to handle this are to generate a random number to append as a parameter to change the URL. The other way is to have your web service to tell the browser not to cache with response headers. I have had IE do this to me and made all my web services send back "Cache-Control: no-cache" to prevent IE caching.