What they describe is not REST. Nowhere in this document mentions hyperlinks, a strict requirement of the REST architectural style.
The best analogy would be a simple web page, which usually contains hyperlinks that a client can follow to discover new information. Unfortunately, web developers' understanding of REST ends with HTML, and they re-invent the wheel, badly, every time they create an ad hoc JSON-over-HTTP service.
There is a standardized solution for machine-to-machine REST: JSON-LD [1], with best practices[2] to follow, and even some formalized specs[3][4]. To Google's credit, they are now parsing JSON-LD in search results, which is much nicer to read and write than the various HTML-based micro-data formats.
On a related note, REST has nothing to do with pretty URLs, naming conventions, or even HTTP verbs. That is to say, it is independent of the HTTP protocol, but maps quite naturally to it.
[1]: http://json-ld.org/
[2]: http://json-ld.org/spec/latest/json-ld-api-best-practices/
How is:
{
"@context": "http://json-ld.org/contexts/person.jsonld",
"@id": "http://dbpedia.org/resource/John_Lennon",
"name": "John Lennon",
"born": "1940-10-09",
"spouse": "http://dbpedia.org/resource/Cynthia_Lennon"
}
(http://json-ld.org/contexts/person
(id http://dbpedia.org/resource/John_Lennon)
(name "John Lennon")
(born 1940-10-09)
(spouse http://dbpedia.org/resource/Cynthia_Lennon))
And it's obviously a student-level exercise to write a validator, spec or grammar for the latter format, while the former is rather more open-ended.
Friends don't let friends JSON.
[1] Which HN sadly turns into a linked mess — Base64-decode the transport representation[2] if you'd like to see the canonical representation.
[2] {KDM0Omh0dHA6Ly9qc29uLWxkLm9yZy9jb250ZXh0cy9wZXJzb24oMjppZDM5Omh0dHA6Ly9kYnBl ZGlhLm9yZy9yZXNvdXJjZS9Kb2huX0xlbm5vbikoNDpuYW1lMTE6Sm9obiBMZW5ub24pKDQ6Ym9y bjEwOjE5NDAtMTAtMDkpKDY6c3BvdXNlNDI6aHR0cDovL2RicGVkaWEub3JnL3Jlc291cmNlL0N5 bnRoaWFfTGVubm9uKSk=}
The answer to that is really simple: JSON is a widely supported standard in many platforms and languages. Whatever the latter is, is not.
What's better than writing a parser for the latter format, is not having to write anything and just using a library, which exists in practically every language for JSON.
Ever heard of LISP, or S-expressions?
There are data interchange formats that use S-Expressions, namely EDN[1]. But JSON remains the most popular format for its widespread support, and its few data types map to most languages.