In the context of http, we have HEAD, but we don't have something DATAHEAD, or METADATA, which would ask the server to provide you what _it_ thinks is the relevant metadata for the endpoint in question. You can fake this by streaming data, or using something like `Content-Range` _if_ you already know what _you_ think the incoming data is, but this means that the consumer has to already know what it is expecting, which kind of defeats one of the purposes of metadata. For example it would be great to be able to send a METADATA request to a url for a zip file and have the server send you back just the central directory (why did they put the central directory at the _end_ of the file?? -> edit: answer: because it was created at a time when you wanted to write the zipped data to disk in a stream so you wouldn't actually know what you had until the end, optimized for writing, duh).
Let's suppose that I have an HTTP endpoint for a doorbell (for some reason). The doorbell resource is represented as http://example.com/doorbell.
There's no RING HTTP method, and I could invent one, but heaven knows if various HTTP middleware would be happy with that. In practice, people do something like
POST http://example.com/doorbell/ring
The problem with this is that you now have a hierarchy of verbs; you have first class verbs (GET, PUT, POST, PATCH, DELETE), and second class verbs which have to be represented as distinct resources. This feels like a hack to me.
But isn't this basically what RPC vs REST boils down to?
As far as I know people tried the RPC way for years then gave up on it and started doing REST. Seemingly because inventing a whole bunch of methods was inherently flawed.