4 ms·

I would love if we could improve on HTTP - even just clearly separating protocol from application would be so great. Maybe dropping some cruft, like the accept

by HdS84 2y ago

I would love if we could improve on HTTP - even just clearly separating protocol from application would be so great. Maybe dropping some cruft, like the accept headers and so on. But yes, doing that is total folly.

alganet 2y ago
The separation is your choice. It is not enforced, as this would require limitations that are not worth having. You can totally drop accept headers if you write your own client and server implementation. HTTP works fine without them. The web as a living organism, not so much. But hey, we don't need content type negotiation, right? XML will reign forever, mp3 is the ultimate audio format. It's not like new codecs and document types appear all the time and some kind of underlying architecture has to reserve space for that kind of change.
- im3w1l 2y ago
  Don't people use ?format=json or /foobar.json anyway?
  - alganet 2y ago
    As I said, if you're writing your own client and server, you don't need Accept. You probably use just one homogenized content type. Using `?format=json` is not offensive. It won't mess up some cache layer like improper status code semantics, so I don't really care that much about these if I see it. I wouldn't block a PR on that. The overall web on the other hand, is supposed to be made of many different client and server implementations. Your browser still relies on Accept headers for displaying images, detecting language, uncompress gzipped responses, resuming paused downloads, showing that JSON API in a nice UI when you open in a dedicated tab, so many things. To me, it makes sense to leverage the same content negotiation ideas for home grown stuff, even if only one content type is being used. It starts being a problem if you're working on microservices, and one of them uses `.json` while other uses `?format=json`, made by different teams. The standard is the obvious solution. Instead, they'll either create inefficient clients full of complexities or fight until one of the workarounds prevail. So much easier to follow the standard.

by HdS84 2y ago

alganet 2y ago

The separation is your choice. It is not enforced, as this would require limitations that are not worth having. You can totally drop accept headers if you write your own client and server implementation. HTTP works fine without them. The web as a living organism, not so much. But hey, we don't need content type negotiation, right? XML will reign forever, mp3 is the ultimate audio format. It's not like new codecs and document types appear all the time and some kind of underlying architecture has to reserve space for that kind of change.

im3w1l 2y ago
Don't people use ?format=json or /foobar.json anyway?
- alganet 2y ago
  As I said, if you're writing your own client and server, you don't need Accept. You probably use just one homogenized content type. Using `?format=json` is not offensive. It won't mess up some cache layer like improper status code semantics, so I don't really care that much about these if I see it. I wouldn't block a PR on that. The overall web on the other hand, is supposed to be made of many different client and server implementations. Your browser still relies on Accept headers for displaying images, detecting language, uncompress gzipped responses, resuming paused downloads, showing that JSON API in a nice UI when you open in a dedicated tab, so many things. To me, it makes sense to leverage the same content negotiation ideas for home grown stuff, even if only one content type is being used. It starts being a problem if you're working on microservices, and one of them uses `.json` while other uses `?format=json`, made by different teams. The standard is the obvious solution. Instead, they'll either create inefficient clients full of complexities or fight until one of the workarounds prevail. So much easier to follow the standard.