Eeek, it currently does! I promise I didn't know at the time but am now reading RESTful Web APIs .
From Chapter 4
Beware of Fake Hypermedia!
Formally speaking, "http://www.example.com/" is a string. The application/json media type doesn’t define any hypermedia controls,so even if some part of a representation really looks like a hypermedia link, it’s not! It’s just a string!If you’re trying to consume an API like this, you won’t get very far dogmatically denying the existence of links. Instead, you’ll read some human-readable documentation written by the API provider. That documentation will explain the conventions the provider used to embedhypermedia links in a format (JSON) that doesn’t support hypermedia. Then you’ll know how to distinguish between links and strings, and you’ll be able to write a client that can detect and follow the hypermedia links.But your client will only work for that specific API. The documentation you read is the documentation for a one-off fiat standard. The next API you use will have a different set of conventions for embedding hypermedia links in JSON, and you’ll have to do the work allover again.That’s why API designers shouldn’t design APIs that serve plain JSON. You should use a media type that has real support for hypermedia. Your users will thank you. They’ll be able to use preexisting libraries written against the media type, rather than writing new ones specifically for your API. JSON has been the most popular representation format for APIs fo rquite a while, but as recently as a couple years ago, there were no JSON-based hypermedia formats. As you’ll see in the next few chapters,that has changed. Don’t worry that you’ll have to give up JSON to gain real hypermedia.
Eeek, it currently does! I promise I didn't know at the time but am now reading RESTful Web APIs .
From Chapter 4