7 ms·
It's always bugged me having to use POST for complex query requests that have "outgrown" URL parameters. Had no idea a new QUERY verb was in the works - that so
by GordonS 5y ago
It's always bugged me having to use POST for complex query requests that have "outgrown" URL parameters. Had no idea a new QUERY verb was in the works - that sounds ideal.
- dylan604 5y agoThis was the first I had heard of Query as well, but admittedly I don't pay too close attention to those discussions.
- Waterluvian 5y agoSame. Also I (foolishly) perceived the spec as being rather stable and was not expecting a whole new verb.
- dylan604 5y agoThere's definitely a lot of misunderstood uses of the verbs, and I've maybe read about them one only a couple of times long long ago. I know POST gets bastardized a lot in attempts to avoid query strings attached to the end of GETs. Lots of people promoting that in tutorials/blogs/etc
- treve 5y agoQUERY seems to be on the path to standization, but using POST if other methods don't fit is/was the right way to do this! Both PATCH and QUERY are newer and they are really specializations of what people used to use POST for.
- throwawayboise 5y agoI have had to bastardize POST in a situation where I had to support an HTTP client that only implemented GET and POST. So the desired action, e.g. DELETE, was included in the POST data.
- dillondoyle 5y agogenuinely curious. why? Does it make a big difference in your code or user experience?
- isbvhodnvemrwvn 5y agoCaching gets rather tricky.
- dylan604 5y agoMaybe because caching POST data is just an odd way of doing things?
- nrmitchi 5y agoYou 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 agoIf 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 agoThen you need to build infrastructure for storing queries. Depending in the specifics of the project, that may or may not be OK.
- dastbe 5y agowhile 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?
- fxleach 5y agoWhy does it bug you?
- toyg 5y agoThe problem with "exotic" verbs is that proxies in the middle will often misbehave when faced with them. There is some old network infrastructure out there.
- wizzwizz4 5y agoWith HTTPS, that doesn't matter.
- mh- 5y agonot really. there are plenty of middleboxes deployed by IT departments that happily mess with HTTPS traffic, too.
- tedunangst 5y agoThere are intercepting https proxies.
- jrockway 5y agoThe proxies in question strip HTTPS, and re-encrypt with a certificate your IT department installed on your device.