A pragmatic take on REST anti-patterns
- Implementing HATEOAS (hypermedia as the engine of application state) using the available tooling is not easy for a majority of developers. And, for consumers, this may dilute the simplicity of the API. You might want to choose a pragmatic REST approach - adopting most of REST but not all or you might create a remote procedure call (RPC) API. Just call it like it is, rather than getting stuck on the REST claim.
- Sometimes, you will need to make concessions based on organizational context rather than best practice, and sometimes there are excellent business and security reasons to heed internal resistance over the purity of design, which does not functionally achieve anything better anyway.
- Avoid making a REST “entity” of your customers. It adds complexity and yet no extra value to the consumer, mixes up the data and the security models by requiring the user to identify themselves by URI. This, in turn, results in a brittle interface, and in a ‘fallacy of nested interfaces’ that even a developer finds hard to parse. Instead, model only what you need to model in your API, not other associated things.
Full post here, 8 mins read