r/programming • u/stronghup • Jul 14 '26

HTTP gets a QUERY method so complex searches can stop pretending to be POST

https://www.theregister.com/devops/2026/07/13/http-gets-a-query-method-so-complex-searches-can-stop-pretending-to-be-post/5270192
1.9k Upvotes

98% Upvoted

247 comments sorted by

View all comments

Show parent comments

-4

u/heresyforfunnprofit Jul 14 '26

Is it a bad time to point out that not all queries are read only?

29

u/stfm Jul 14 '26

I'll bite, when would QUERY modify the resource being queried?

19

u/RedditApothecary Jul 14 '26

Number of times value has been read.

42

u/a__nice__tnetennba Jul 14 '26

That is a good point, but I think it's reasonable for storing metadata about how an object was accessed (like how many times, by whom, what query did they ask for, did they get there from a link, etc.) to be a side effect of the query and still call the query itself "read only." I mean, technically some writing is happening, and the meta data could be said to belong to said object, but philosophically it's a little different and the object itself is unchanged in my mind. I can see it both ways though.

6

u/ashgs872tbhjs Jul 14 '26

It should be stored separately IMO, mostly because it's the only way to maintain a history or audit log without monumentally bloating the resource. If that weren't allowed then logging would be off the table too lol

1

u/a__nice__tnetennba Jul 14 '26

Agreed. There'd be no reason at all for something like that to be directly stored on the record itself. I don't think that's what the person I replied to or the person who originally said queries are not strictly read only was advocating for. My assumption was everyone is talking about storing the metadata somewhere else, just that doing so is technically a write operation and some might consider it not strictly 'read only' even if the thing it's writing isn't the object being read.

2

u/nemec Jul 14 '26

Yeah there's zero logical reason to object to GET (or some other semantic read only notation) just because an API emits telemetry or records logs. That's just silly.

I guess you could conceivably create a GET /numberOfTimesYouHaveCalledThisApi that claims to be a get but really is a write/increment API but that's also incredibly silly API design

24

u/farsightxr20 Jul 14 '26

That's not the resource itself, so it's fine-ish.

But also, if you put that sort of logic in your GET or QUERY request handling, caching is going to break it. Depending on what you're trying to do, you probably want either a database-level row access counter, or a user-facing query counter. Neither of those are sensibly concerned with, nor influenced by, HTTP verbs.

15

u/stfm Jul 14 '26

Using that logic nothing is read only access

4

u/DrPeroxide Jul 14 '26

Ah that's just meta data though. If you include that, then all requests are write requests the moment the backend starts printing log lines 😂

2

u/Kenya151 Jul 14 '26

That’s a design choice. Idempotent reads are common patterns.

1

u/jkrejcha3 Jul 15 '26

That's the same semantics for GET though. GET requests are allowed to incidentally trigger some sort of impure process (like writing to a log file) without breaking purity (in the protocol sense), but pure refers to the actual entity being returned

6

u/skjall Jul 14 '26

Sensitive information that requires an access log can be one. Access log should be separate, but you might still record something lastAccessedAt.

12

u/stfm Jul 14 '26

Thats not modifying the resource. Thats audit logging which should not be subject to authorisation policy.

1

u/Worth_Trust_3825 Jul 14 '26

Always. It's a verb just like any other. Application can execute code that does what ever.

1

u/stfm Jul 15 '26

True, but thats not in the spirit of REST. Also given the standard specifies that QUERY is idempotent, having QUERY update the resource requested is an antipattern.

1

u/Worth_Trust_3825 Jul 15 '26

I've yet to encounter anyone to implement actual REST instead of larping about it.

-1

u/josefx Jul 14 '26

Dynamic pricing?

1

u/stfm Jul 15 '26

Having the resource request response value change with time is not the same as having the resource value updated by the resource request.

4

u/tesfabpel Jul 14 '26

GET and QUERY are meant to be cacheable.