POST is effectively the catch-all verb. There's nothing that violates HTTP spec in having a site that only has one endpoint, `POST /`, that specifies the actual JTBD somewhere in the request body. It's simply nasty and unidomatic.

c.f. https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

User agents still don't support PUT et all in forms without JavaScript -- you're limited to GET/POST, c.f. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/fo...

> User agents still don't support PUT et all in forms without JavaScript

So why were they in the original HTTP spec if they weren't supported by original HTTP agents?

> So why were they in the original HTTP spec if they weren't supported by original HTTP agents?

Bad assumption.[1]

HTTP/1.0 spec (1996) defined GET, POST, and HEAD.[2]

HTTP/1.1 spec (1997) defined all of the other, newer methods.[3]

> supported by original HTTP agents

The first web browsers I know about were Mosaic (1993) and Netscape Navigator (1994) predating the HTTP/1.0 RFC.

[1] https://stackoverflow.com/questions/41411152/how-many-http-v...

[2] https://tools.ietf.org/html/rfc1945#section-5.1.1

[3] https://tools.ietf.org/html/rfc2068#section-9

What I still don't understand is why they didn't add support for them to forms.

They were only added in HTTP 1.1, and it's initial drafts had even more variants that were clearly for file management: https://tools.ietf.org/html/draft-ietf-http-v11-spec-00#sect...

This is before me being old enough to follow technology, so below is a good portion of conjecture and hearsay (I'd love to be corrected by someone who actually remembers it):

Tim Berners-Lee initial web browser was intended as an editing tool as well as a viewer, and these ideas came back when they went to write up HTTP as a a "proper" IETF standard. Not uncommon (bit less so today, but back then especially) to design specs with what they thought it should do, not what they'd tried/done in practice. Making an official spec is the chance to get this stuff in.

At some point, a bunch of the file-specific stuff was split off to WebDAV as an extra thing (work on that started 1996, HTTP 1.1 was finished 1997) - or rejected and WebDAV created as a new home for those ideas? But PUT among some others survived.

You’d use forms with buttons in them, and style them to look however you like. I used to do this a lot when building pages using progressive enhancement; it’s less common now.

An “upvote” is probably an idempotent action. Calling an “upvote” endpoint moves an object into an “upvoted” state, regardless of what it’s previous state was. However, it’s probably semantically a PATCH, since it’s a partial update of a resource.

There is no real disconnect here.

I see things like <a> GET links for destructive operations all the time - are they in violation of the HTTP spec? Do browsers speculatively load these resources and delete things without the user interacting?

It’s definitely a problem. You should never have any destructive or modifying actions of any sort done from a GET request. In addition to browser prefetching, users might share a link without the receiving user realizing they are taking an action as soon as they click the link, which can be a source of security issues.

That being said, I too have seen things like this on the Internet. I would assume Google has some sort of heuristic to determine whether or not they can safely prefetch a link, but who really knows? You should absolutely avoid making this mistake in your own code.

You can have buttons and forms with pure HTML. Sure links are all GET requests, but you can specify the method of a form.