3 ms·
I really like his articles on HTTP APIs. I learned quite a lot from them. What he writes makes a lot of sense, except for the "HATEOAS" part. What he consisten
by waxjar 14y ago
I really like his articles on HTTP APIs. I learned quite a lot from them. What he writes makes a lot of sense, except for the "HATEOAS" part.
What he consistently doesn't tell us is why it's necessary and how exactly we're supposed to implement HATEOAS—wouldn't HEAS be a much better acronym?—in our APIs.
I'm guessing the reason why is so API wrappers would be trivial to write. A single library could simply consume a "standards-compliant" API. What that means I do not know.
That's where the how comes in. It seems from the XML example that these links have to in the body of the response. That would mean every single response format has to be dealt with separately. That's not very practical. I also have no idea how something like it would look in JSON for example, let alone how it should be parsed in a meaningful way.
- zachrose 14y agoWhy not: { id: 35, name: "Kennedy, John F.", predecessor: { id: 34, name: "Eisenhower, Dwight D.", href: "/presidents/34" }, successor: { id: 36, name: "Johnson, Lyndon B.", href: "/presidents/36" } }
- justincormack 14y agokill the ids, URLs are ids having extra ones just makes life harder. You could have an ordinal for presidents of course.
- icebraining 14y agoBesides killing ids, use full URIs, not just the path. That enables you to replace the links to other domains, possibly to a third-party. Just like we often link to Wikipedia on our posts, you could decide tomorrow that your service should link to dbpedia.org or Freebase instead.