Same here - I keep coming back to "are they just talking about webhooks? or are they also talking about some kind of persistent http streaming api?"
I'm thinking these are just Webhooks, but the REST part is throwing me off because I think of it more as a consumption concept (consuming resources, etc).
Update: Found this, which I think explained it best: "REST Hooks itself is not a specification, it is a collection of patterns that treat webhooks like subscriptions. These subscriptions are manipulated via a REST API just like any other resource. That's it. Really." - but it was in /docs, not the main page.
Oh, ok. That makes sense. I implemented that for Emma a few years ago but I don't know if I made it up or saw it somewhere else first. Probably the latter.
It is just a pattern around making traditional webhooks another resource on your existing REST API so you can programmatically control subscriptions/callbacks/webhooks/etc. instead of asking users to copy-paste URLs.
Thats what it appears to be, but on closer inspection it doesn't go that far. They give an example rest path of /subscriptions but i cant tell if its an example or meant to be used as a standard endpoint name.
1. Webhooks
2. A subscription layer via REST
Several major players already are doing this but it doesnt have a name.
REST Hooks are a way to consolidate that momentum and push it to a broarder audience.