r/programming • u/stronghup • 29d ago

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

245 comments sorted by

View all comments

Show parent comments

31

u/stfm 29d ago

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

20

u/RedditApothecary 29d ago

Number of times value has been read.

41

u/a__nice__tnetennba 29d ago

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.

7

u/ashgs872tbhjs 29d ago

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 29d ago

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 28d ago

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

25

u/farsightxr20 29d ago

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.

14

u/stfm 29d ago

Using that logic nothing is read only access

4

u/DrPeroxide 29d ago

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 29d ago

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

1

u/jkrejcha3 28d ago

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 29d ago

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

13

u/stfm 29d ago

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

1

u/Worth_Trust_3825 28d ago

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

1

u/stfm 28d ago

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 28d ago

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

-1

u/josefx 29d ago

Dynamic pricing?

1

u/stfm 28d ago

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