-
-
Save steveklabnik/2004584 to your computer and use it in GitHub Desktop.
| Hypermedia designs scale better, are more easily changed and promote decoupling | |
| and encapsulation, with all the benefits those things bring. On the downside, | |
| it is not necessarily the most latency-tolerant design, and caches can get stale | |
| if you're not careful. It may not be as efficient on an individual request level | |
| as other designs. |
Hrm, yes. This paragraph came out of doing several rounds of reductions on Section 5.1 of Fielding's thesis, and he makes no mention of tehse kinds of things. I'm not sure where that kind of thing fits in, but I'll think about it.
I've found that doing that work is actually less work than the usual 'duplicate business processes, format URLs, etc' work that RESTful (:wink:) clients have to do.
I agree on it being less work in the long run.
It does seem to catch devs (who are unfamiliar with the benefits of Hypermedia) off guard when they are implementing the code to interact with a discoverable API, they sometimes really badly just want to hard code urls directly into their code etc.
Hypermedia designs promote scalability, allow resilience towards future changes, and promotes (should be 'promote')
"Hypermedia designs scale better, are more easily changed and promote..."
You may not love my exact wording (I'm not crazy about the "are more easily changed"), but I'm not crazy about "allow resilience towards". I want more verbs and less nouns. :)
@telemachus yeah, I agree it's awkward. I think I like your wording. More revisions.
Consumers/ clients of these kinds of APIs also have to do a little extra work; doing discovery, making sure media types line up with the requests, etc.