I like that but I’m not so sure.

Hyperlinks aren’t interactive. They’re bookmarks. When I click on a link have I interacted with the page? In a sense I have. But have I changed its state? No. I’ve just moved from one static place to another static place.

Hyperlink + query parameters were a way to provide interactivity (with a server roundtrip of course)

For example, sorting a table could be achieved by having the column headers be a link to the same url with ?sort_by={colname}

And then the server sees that and sorts and returns.

Same with "dynamic" number of input fields. When the add field link is clicked you reload with ?num_fields=2

To me that feels like a technicality. It’s the same experience you’d get with a button + JS except with more latency.

> Hyperlink + query parameters were a way to provide interactivity (with a server roundtrip of course)

Not if you want to be pedantic. At least, if you want to follow the rules, GET requests should never change visible state on the server.

So the interactivity would be limited to searching/filtering existing content, but you wouldn't be able to add new content.

For that, you'd need POST requests, i.e. buttons.

Cool comment, got me thinking a bit and I’d like clarity if you don’t mind.

Sorting in a GET request param doesn't alter the server's state. It only changes the data representation, not the underlying resources.

This fits "safe" method def (RFC 9110) https://www.rfc-editor.org/rfc/rfc9110.html#safe.methods

But I agree sorting feels like it’s doing “something”… which is where I got stuck thinking about this.

But are you saying that the client view state (example of the sorted data) should not be handled by the server via GET?

If that’s what your are thinking, I’d like to learn more on this rule.

Ah, sorry. No, I just left out sorting for brevity. Sorting the result of a query is a pure function of its parameters and the existing server state, so it would be perfectly valid to do server-side in a GET request.

But changing the "default" sort order of a resource (either by physically shuffling the rows on disk or by setting some server-side global variable) would not.

I think it's the difference between making a sorted copy of a list (while leaving the original list untouched) and inline-sorting the list.

Same applies to filtering.

Even storing the processed results in a cache does not validate idempotency, because from a client's POV, the behavior of the next request would be the same, whether the server calculates the result fresh or pulls it from the cache.

(Edit: Realized, I mixed up "idempotent" and "safe" methods there. I was talking about "safe" methods - but those are what applies to GET requests and what can be represented by a hyperlink)

This is why idempotency is defined through visible state on the server. What happens on the server doesn't matter, but a GET request should not change the results of any subsequent future requests, as visible to the clients. E.g. adding or modifying a post or a blog entry via a GET request would break the rules.

(Nothing stops you in practice from ignoring that requirement, but it can lead to ugly surprises, such as a crawler triggering a mass deletion because it crawled the /delete links)

Yeah but that was also implemented as a button, right? input type="submit" would display a button in 1993 AFAIK. No javascript and acted like a hyperlink - but still a button.

The most noticeable difference back then (before JS and before CSS) was that browsers displayed very visibly the destination of links, while input buttons were totally opaque. We created buttons with images inside an a href tag to make styled (in photoshop) buttons that behaved like links and generated a GET request. We could add a query string. The only way to make a POST request was a button inside a form.

> Hyperlink + query parameters were a way to provide interactivity (with a server roundtrip of course)

No server processing needed: the page returned can be identical with an onload function that grabs the GET parameters and does the processing on the client to, for example, reorder the rows of a table.

The author probably mean hypermedias. Buttons and links are just means, but no interactivity even happens without the user clicking or moving their mouse.

Now we can of course talk about client-only interactivity (as in thick clients like paint apps) but that's not the topic.

Two exceptions could be: - url hash links and the css :target pseudo class. - Links that target iframes

Not suggesting to use these patterns liberally, but they do work for light interactivity.

those are just extra features that let hyperlinks behave like buttons though. Of course, this is under the strict definition that a "hyperlink" is a link between two web pages.

I am not sure if the author actually put any thought into the foundation of interactivity on the web, or if they just asked the AI to write a nice-sounding introduction to their article about new button capabilities.