Hyper-Text Transfer Protocol is, by some measure, the most popular way for computers to talk to each other on the Internet1.
Generally speaking2, clients (like browsers) talk to servers using a set number of HTTP "verbs". This tells the server what sort of thing the client is trying to do.
The two most popular3 verbs are probably POST - which lets you send data to a server - and GET - which lets you get data back from a server.
There are other HTTP verbs like DELETE to delete data, and PATCH to change data. But it is a fairly limited set of actions.
What would be some interesting or useful verbs to add to HTTP's vocabulary?
Payments
I think the most obvious one would be BUY.
A client sends a GET request to a server. The server responds with HTTP Status 402 Payment Required which includes payment details. The client sends BUY along with confirmation that they've sent the payment4. The server responds with the content.
Mistakes
What about if you make a mistake using POST, PUT, or DELETE? Wouldn't you like to use HTTP UNDO?
Possibly it’s forgive, but … UNDO
— ཀ།༨ཇ ་།་འ།སབཇའ (@chthonicionic) August 25, 2022
Let's not get in to a discussion about idempotency5
Halt And Catch Fire
Some CPUs have peculiar instructions which can be (ab)used to make them self-destruct. So why not extend that to HTTP⸮
Detonate.
— Charlie O’Hara (@whalecoiner) August 25, 2022
Remember that scene in every Star Trek movie where the captain shouts "Computer! Initiate self-destruct sequence. Confirmation code Heliotrope Banana Daguerreotype." Let's extend that so that clients can request that a (virtual?) machine shuts down.
Won't you please please help me?
APIs - and other services - are sometimes difficult to use. In the Linux6 world we just type -h or --help after every command and get some more-or-less useful help text.
So what about HTTP HELP? Return a machine- or human-readable document explaining what commands the server responds to. Pretty sure that'd be useful.
Who are you? Who? Who?
Cookies have gotten out of hand. And, frankly, they're a security disaster. Why should a server send a client a token to store? Let's reverse that with HTTP REMEMBER.
The client sends the server a suitably complex string and a validity period. The server is then compelled to remember the client's authorisation. Perfect7!
And when you want to log out, an HTTP FORGET is easier than clearing your cookies. Imagine that, a log-out button in your browser which worked everywhere...!
Over to you
So, if you were made God-Emperor-For-Life of the IETF, which new HTTP verbs would you add?
- I just made up that "fact". But it feels right, doesn't it? ↩
- It is a lot more complicated than that. If you want to have a rant about precise definitions, please do so on your own blog. ↩
- I can't be bothered to actually back this up with statistics. ↩
- How? I dunno? A signed response from a payment provider? A crypto receipt? Something like that. ↩
- FINE! Have a discussion about the implications. It bet it won't end in bloodshed. ↩
- …or as I’ve recently taken to calling it, GNU plus Linux… ↩
- I'm not sure this makes any more sense than doing it the cookie way. But, hey, that's what brainstorming is for! ↩
