[hlandau]

The whole point of my article was that constraining things to a small, limited set of verbs is actually a bad idea.

Theoretically you can just make up your own verbs for HTTP and use those. In practice people stick to the common ones because they're well supported. This leads to people massaging a problem domain into the straightjacket of GET/PUT/POST/PATCH/DELETE, regardless of how well it fundamentally fits that set of verbs. (I'm also convinced nobody actually knows what "REST" means, but that's another rant for another time.)

[mpweiher]

The WWW kinda shows that, empirically, having a small set of verbs is a pretty darn good idea. CORBA and most call/return programming has shown that having to invent new verbs all the time ( getX(), getY(), getTopLeftCorner() ...) gets old really fast.

The other thing a common set of verbs gets you is generic endpoints and, even more interesting, generic intermediaries.

My approach is to let resource-y things be resource-y, and let verb-y things be verb-y. After all, language has nouns and adjectives and verbs, maybe there is a good reason for this diversity?

So

     var:myhome/doorbell ring.

(Although I am highly skeptical of IoT, so somewhat wary of such an example).

If you wanted to model this in a more resource-y way, you could doL

     var:/myhome/doorbell/ringing := true.
     // delay
     var:/myhome/doorbell/ringing := false.

That would also get you the ability to read the status of the doorbell.

> I'm also convinced nobody actually knows what "REST" means

Considering REST is the basis of the WWW, the largest and arguably most successful information system of all time, I would say (a) most people understand it "well enough" to work with it and (b) if we don't understand it, it behooves us to make an effort to do so.

Because it's not like there haven't been other attempts to build something like the WWW, they just failed miserably.

[k__]

What other verbs could be needed?

[tgbugs]

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).

[hlandau]

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.

[k__]

Ah okay.

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.