5 ms·

> but only over HTTP POST so it broke caching on CDNs. That's why when making request related to realtime data in the server, a POST is always needed! GET is

> but only over HTTP POST so it broke caching on CDNs. That's why when making request related to realtime data in the server, a POST is always needed! GET is ONLY get for static content.

jrochkind1 3y ago
That is... not right. While POST is effectively never cached, GET isn't always either. Cache headers should be set properly on GET responses, indicating desired caching behavior (which is more than 'on' or 'off', as the OP gets into), on any content, static or not. The fundamental difference between GET and POST in http is idempotency. An non-cacheable response to an idempotent request is sometimes a (intentional, desirable) thing, which is why you can make GET responses non-cacheable if you want. Static content isn't the only thing you might want to be cached, there are all sorts of use cases for caching (which again can be configured in many ways, it's not just on or off) for non-static content.
- SkyPuncher 3y ago
  While you’re right in theory, it doesn’t always work in practice. Some systems fail to respect caching headers. Further, in my experience, intermediate caches are mostly useless for non-binary product data. Either you need to make a round trip or you don’t. Sure, you can cache and return “not changed”, but you still get the latency. Just returning the data often isn’t much slower. POST avoids all of those issues by pretty much saying “give us what we neeed every time”
  - thejazzman 3y ago
    > Some systems fail to respect caching headers. Don't we call those bugs? http has a pretty well defined spec?
    - SkyPuncher 3y ago
      Customers don't care what's defined in the spec. They care how it works.
  - jrochkind1 3y ago
    By that logic, would you write a web site where every link was actually a POST unless it was to "static content"? That would be a disaster, no? I guess the person I was replying to, and you, were talking about Javascript API calls rather than ordinary HTML executed by a "browser". It still seems like a wrong idea to me, but if this is what you do on actual apps and have success, I guess that's a thing.

> but only over HTTP POST so it broke caching on CDNs. That's why when making request related to realtime data in the server, a POST is always needed! GET is ONLY get for static content.

jrochkind1 3y ago

That is... not right. While POST is effectively never cached, GET isn't always either. Cache headers should be set properly on GET responses, indicating desired caching behavior (which is more than 'on' or 'off', as the OP gets into), on any content, static or not. The fundamental difference between GET and POST in http is idempotency. An non-cacheable response to an idempotent request is sometimes a (intentional, desirable) thing, which is why you can make GET responses non-cacheable if you want. Static content isn't the only thing you might want to be cached, there are all sorts of use cases for caching (which again can be configured in many ways, it's not just on or off) for non-static content.

SkyPuncher 3y ago
While you’re right in theory, it doesn’t always work in practice. Some systems fail to respect caching headers. Further, in my experience, intermediate caches are mostly useless for non-binary product data. Either you need to make a round trip or you don’t. Sure, you can cache and return “not changed”, but you still get the latency. Just returning the data often isn’t much slower. POST avoids all of those issues by pretty much saying “give us what we neeed every time”
- thejazzman 3y ago
  > Some systems fail to respect caching headers. Don't we call those bugs? http has a pretty well defined spec?
  - SkyPuncher 3y ago
    Customers don't care what's defined in the spec. They care how it works.
- jrochkind1 3y ago
  By that logic, would you write a web site where every link was actually a POST unless it was to "static content"? That would be a disaster, no? I guess the person I was replying to, and you, were talking about Javascript API calls rather than ordinary HTML executed by a "browser". It still seems like a wrong idea to me, but if this is what you do on actual apps and have success, I guess that's a thing.