4 ms·

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 ne

• 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