> Mostly, it means using HTTP verbs on URLs to represent create/update/read/delete. (IE, POST/PUT/GET/DELETE)

Actually, REST has nothing to do with "using HTTP verbs". HTTP is a key part of the Web architecture by which REST was inspired (and HTTP/1.1 was itself designed to make the web more RESTful), but REST isn't dependent on a communication protocol -- indeed, REST used as defined is largely protocol neutral, and can even freely mix communications protocols.

> There are other intricacies like HATEOAS (which sounds like a horrible breakfast cereal), but it basically mostly comes down to updating resources using http verbs.

Using hypertext representations to transfer state is not just a peripheral "intricacy" of REST, it is central to it. That's why its called "representational state tranfer".

> (Personally I don't get the reverence it gets since it's basically just about verbs and locations, but whatever, it works well enough).

If you are going to reduce REST to a simple "its all about" statement, then "verbs and locations" are the wrong thing -- on that level, REST is all about resources and their representations. That's, again, why its called "representational state tranfer".

Insofar as it is about communications protocols at all, its about using them in a standardized manner not specific to the particular resources.

No.

REST has nothing to do with HTTP. That is like saying that poetry has means using english to make sonnets that rhyme.

REST stands for representational state transfer. It is a software architecture style that sets up constraints on objects, and other data structures within a distributed network.

That is it. HTTP attempts to provide a way of doing REST, but you can even use HTTP to do things in a non-rest way.

I think the reverence it gets is owed to people desperately wanting to follow a standard when it comes to offering an HTTP API. You want to make it as easy (=standardized) as possible to use it, and REST has emerged as a viable standard.

I think the ease of use isn’t just about being standardized, it’s also about being simple. REST (in)famously doesn’t support higher-level concepts like transactions neatly, but it provides the magic four database operations if you only need to work with a single resource at once, and for many applications that is sufficient.