3 ms·
Consider a service powering a right click context menu. REST's HATEOAS constraint is a generalization of this idea - decoupling the API from the client. A lot
by dustingetz 14y ago
Consider a service powering a right click context menu. REST's HATEOAS constraint is a generalization of this idea - decoupling the API from the client.
A lot of popular web APIs, e.g. Twitter, do not embrace HATEOAS, which is why API changes break clients. Which isn't really a big deal if you control all the clients.
- shawn-butler 14y agoI've never fully bought into this constraint, I guess. I can understand how it might be useful for machine-to-machine consumption of an API (which seems to be a sort of holy grail) or for an API that is meant to last for say a decade and be self-documenting between generations of programmers. But I guess it seems like neither of those are domains where anyone I know is really working; admittedly entirely anecdotal. API seem to change or get replaced by "the next best thing" on the order of months or years. And doing HATEOAS seems like making a c++ program const-correct. Always starts out well but pretty soon isn't viewed as worthwhile by powers that be. Do you have an example of a really good HATEOAS public API that is widely consumed?
- w0utert 14y ago>> And doing HATEOAS seems like making a c++ program const-correct. I would argue that cons-correctness is probably one of the most important considerations of any public C++ API, so not really the best analogy ;-). Try to refactor some actively used C++ framework API that never bothered about const correctness some day, weeks of fun and bickering with your API clients guaranteed.