Okay, first this was of course nit-picking, as I just hoped to get across the point, that REST is not just pretty URLs.

> Except those are of course guidelines

Well, obviously.

> Instead of a list of methods, you get a list of methods (which do not have to stay the same, by the way) and a tree of resources.

Well, yes. But those are already established and if you're exchanging representations as REST demands, you shouldn't need anything more than GET, POST, PUT, DELETE and PATCH to manipulate data.

> Theoretically you should be able to crawl a REST API using only the document types and the root URL, I don't think I've ever seen a "public" API letting me that.

Sun tried to do that for their cloud computing API, I think they're the ones that created the term RESTful where you'd use elegant concepts like <link> in your representations to advertise available actions.

> Yes, because if you POST the same thing twice you don't risk fucking things up...

If you do it properly with versioning/unique ids where appropriate, then all your calls should be re-triable or at least fail.

> Oh you should be using PUT, not POST, you say? Good luck getting that one in browsers.

You can create browser API (with proper CSRF protection etc. btw) that acts as a [server-side] client to your REST API. Also I see most usage of any REST APIs from browsers coming from Javascript based clients, which usually don't impose such limitations.

>Instead of a list of methods, you get a list of methods (which do not have to stay the same, by the way) and a tree of resources. Theoretically you should be able to crawl a REST API using only the document types and the root URL, I don't think I've ever seen a "public" API letting me that.

Oh yes you have. Ever browsed a ftp server with your browser? That is a REST API, using HTTP and FTP for transportation and HTML and WHATEVER for the actual data. You can start from the root of the server (or more commonly, from /pub/) and crawl through the file hierarchy as much as you like.

But your point is valid. Not many APIs allow to "crawl" the data, even though one of the four guiding principles for interface is: Hypermedia as the engine of application state "If it is likely that the client will want to access related resources, these should be identified in the representation returned, for example by providing their URIs in sufficient context, such as hypertext links."

REST is an architecture style, not a protocol. HTTP is protocol well suited for use in a RESTful system. The API in question violates REST (atleast) by not using the methods provided by HTTP.

> Except those are of course guidelines, the API implementor is free to entirely disregard them (much to the danger of everybody)

Witness the Google Web Accelerator debacle.