The curse of HATEOAS

From time to time i land on HATEOAS discussions, and every time i see stuff like ‘HATEOAS is the key to change your API without breaking clients’. In that very moment i want to punch that very so-called developer in the face as hard as dicks are in lousy jokes.

For decent humour’s sake, the only key to not break API once it’s out is not to change it at all. Public API is stable once it has been released, and if you’re thinking about changing it not as a catastrophe, you deserve to be laid off next hour; if a developer is going to break the API and walk away just this, well, that’s the developer that requires to be fixed urgently. The open-closed principle, the semantic versioning, the “deprecate methods, don’t rename” paradigm — all those things are practically screaming to you from other side of the screen: DO NOT BREAK THINGS, RELEASE NEW VERSIONS OR JUST ADD NEW FUNCTIONALITY. If you want to change your signature dramatically, consider bumping your /v{N} prefix and release new version of your API. Because whenever your faulty brain goes into another cognitive damage-cycle presenting yourself in shining lights of the Impact you’re doing with few lines of code, whenever it tells you’re Changing The World, it doesn’t realize your impact is mostly negative and the world would be better without developers of that kind.

HATEOAS IS NOT a solution targeted at fixing broken API, and it never was.

Smash it with a hammer on your own car.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.