[dragonwriter]

verbs don't identify a resource, so why would they be in a URI?

A separate format to serialize a request spec is a good idea, sure, but it is a distinctly different thing than the URI of the resource referenced by the request.

[nerdponx]

Is that not just the HTTP 1.1 format? It's a perfectly readable plain text format.

[crazygringo]

I'm pretty sure you know what the parent means.

Forget about what acronyms stand for. The thing that hyperlinks point to and you can type in your browser bar is called the URL or the link.

And the point is that being able to specify a verb and headers in a link would be super useful in certain situations.

Continue to call it a URL or URI and just change the "R" in those from Resource to Request, semantics problem solved. Or invent a new URA where "A" stands for "action" and it's a valid hyperlink. The naming of it is the least important part here.

[slondr]

We already have a format to identify an entire request including verb and headers. It’s called HTTP.

[crazygringo]

Yes, but it can't be used as a hyperlink or typed into the browser bar.

HTTP is a two-way messaging protocol. What's being talked about here is the capabilities in hyperlinks. Totally different.

[slondr]

That sounds like a deficiency of browsers, not of URLs. Browsers can already make arbitrary HTTP requests, and there are some rudimentary ways to expose this in hypertext (such as forms or XHR), but there’s nothing stopping a browser from letting you dump a full HTTP request into a text field and sending it.

[9dev]

You're ignoring such a huge part of the HTTP specification there, like request idempotency, caching, the security model, and surely stuff I'm forgetting right now.

HTTP, at its heart, is a way to compose an action from a verb and a noun - such as "get this", or "update that". The request method, or verb, is intertwined with the URI, or resource, the noun - together, they form the action the user agent intends to carry out. "GET /foo" is entirely distinct from "POST /foo", and there are lots of considerations why it has been implemented like that. I cannot recommend reading the spec (or letting ChatGPT summarise it for you) enough, it will really make more sense.

Having said all that, I know what situations you are referring to - say, issuing a PATCH request with an HTML form, or circumventing some redirect bug with a POST request. Still, all of those problems hint at some other, more general issue, and solving such inconvenience would come at the price of a completely broken HTTP specification. Protocols like email, or HTTP, have only been around for so long because they were designed elegantly and carefully. Let's not break that for convenience' sake :)

[crazygringo]

Believe me, I've read the spec as I've wound up implementing HTTP servers from scratch multiple times a couple decades ago.

None of this suggestion is about incorporating all of HTTP's functionality. It's just the situations that you say you know I'm referring to -- verbs, things like authorization headers, a POST payload.

Expanding the functionality of hyperlinks wouldn't break anything about HTTP. It would just allow more requests to be defined in a single line of text (a hyperlink), rather than requiring lines of JavaScript to define. The browser (or cURL or whatnot) would convert the link to the actual HTTP request. Zero changes to HTTP.

[9dev]

Well. Hyperlinks are part of the spec though, and if you modify them and expect clients to know how to deal with that, you’ll need to modify the specification, and that implies you need to define how those changes affect caching, Proxies, and the security model. There’s a pretty good reason you send credentials in a header, not the URL. What’s my browser supposed to show in the history?

What you’re looking for is a browser extension, not a haphazard URI change.

[afiori]

you can call it https+rpc and be formatted like

https+rpc:||news.ycombinator.com|reply?id=36096485&goto=item%3Fid%3D36095032%2336096485#method=PUT#H-Accept=text/html

with | instead of / to workaround this site encoding