4 ms·

genuinely curious. why? Does it make a big difference in your code or user experience?

• isbvhodnvemrwvn 5y ago
  Caching gets rather tricky.
  • dylan604 5y ago
    Maybe because caching POST data is just an odd way of doing things?
• nrmitchi 5y ago
  You often want to cache results of complex queries. If these are POST, you find yourself trying to conditionally cache POST requests, which opens up a whole new class of caching bugs.
  • NavinF 5y ago
    If the queries are that long (over 2k-ish bytes), wouldn’t you wanna write a query file with POST and then execute it by name with a GET?
    • wtetzner 5y ago
      Then you need to build infrastructure for storing queries. Depending in the specifics of the project, that may or may not be OK.
    • dastbe 5y ago
      while that could be preferred, here's some reasons why it may not be 1. pre-existing behavior. maybe queries have only started getting big enough to where this mattered, but all of our existing clients communicate the original way and won't migrate 2. more complex behavior on clients and services as you've now introduced a new stateful resource between client and service. should clients store query ids, or does the service handle idempotency? what db does the service use to store queries? how do we limit stored queries? do clients have to manage number of queries stored? does the service?
    • cryptonector 5y ago
      That takes two steps, needs authorization, and needs queries created that way to be stable so that when you execute them with GET you know what you're executing. This is a lot of application logic to add just to avoid adding a QUERY method. It's just too much.
    • fooey 5y ago
      and you just re-invented stored procedures and/or RPC pretty much the same pro's and con's too safer, more controlled, better optimized but it's more limiting, another dev dependency and a responsibility bottleneck
• kuhzaam 5y ago
  Some popular web frameworks limit the size of the query string
  • cj 5y ago
    Popular browsers limit the size of the URL (not specifically the query string, the whole URL). If frameworks limit qs size, it’s most likely due to upstream browser limitations.
  • matsemann 5y ago
    CloudFront does as well. Bit us when Adyen didn't support a POST-workflow for our case, and at the time sent a GET request a thousand kilometers long instead.
  • dillondoyle 5y ago
    AFAIK Chrome et al do too. at a couple thousand of characters last I searched for an answer. I did write some tracking code that ended up having really long strings and a ton of parameters and wrote it to break into multiple requests at like 1800.
  • patrickthebold 5y ago
    also things like proxies/load balancers. I remember being happy that I figured out how to configure my framework to allow a long url, but then sad that something in between wasn't allowing it.
• tptacek 5y ago
  Yes! It can make a big difference! For instance: in a single-writer many-read-replica deployment, GETs might be routed automatically to replicas, while POSTs might have to be routed to the writer. You can design around it (for instance, route everything to replicas, catch exceptions on writes, and replay to the writer), but it's simpler and marginally faster to simply distinguish based on the verb.
  • abhishekjha 5y ago
    > route everything to replicas, catch exceptions on writes, and replay to the writer), I am curious about the specifics here. Do you do it at the application level or proxy level? Does doing it at the app level require that all the requests can be routed to any DB instance regardless of whether they are master or slave. A write to a mster is passed through. A read to a master is routed to slaves LB. A read on slave is passed through. A write on replica is routed to the master. Does this look like a sound design?
    • tptacek 5y ago
      There's a bunch of different ways to do this, and upthread I just gave a sketch. I can tell you what we do at Fly.io --- or rather, what we suggest our users do: * We have an HTTP header you can set in a reply that says "replay this request elsewhere". * We boot up clusters of Postgres servers in read-replica configurations --- a single writer, lots of readers. * If you try to write to a read replica, you get an error from Postgres, and your framework passes that error up to you. * We suggest our users catch the exception and set the "replay elsewhere" header to redirect the request to the write master. And that's pretty much it. Most apps are read-heavy. Reads get serviced from replicas (and, usually, close to their users --- that's the point of the service we built) and writes go to the single write master. You don't write any serious code to make that work. But if apps could reliably say "a POST isn't just a complicated GET, but is almost certainly changing mutable serverside state", this would be an even easier problem; you'd just have the CDN route POSTs to the write master region, and GETs to the nearest region, and you'd be done. You can architect your apps like this today, I guess, using QUERY or abusing PUT or something. My point is just that there's significant value in being able to shift all the read-only operations out of POST.
• cryptonector 5y ago
  If you can only use POST, then the query is by definition not safe in the HTTP sense even if it would be with a QUERY method: POST is defined to be not-safe. So an HTTP framework would not retry, moving retry logic into the application. If you can only use POST, then you also can't cache the result because POST is not safe: you've no idea if the same POST is intended to produce the same response.
  • dillondoyle 5y ago
    Makes sense on the browser retry. Can cache in your JS code. But for browsers: Do browsers respect cache headers for GET requests to say an API endpoint? maybe with an etag?
  • jayd16 5y ago
    POSTs are cacheable with a cache response header. POST MAY NOT be idempotent. That doesn't mean they MUST NOT be idempotent. If you have the cache header, you do know what the intention is.