Hey thanks for the in-depth feedback/discussion! I've definitely fallen prey to the anti-pattern you lay out here. And it's super hard to not fall in to a kind

Hey thanks for the in-depth feedback/discussion! I've definitely fallen prey to the anti-pattern you lay out here. And it's super hard to not fall in to a kind of sunk-cost fallacy where you begin to limp along until eventually giving in and - as you mention - throw it out to build with a better understanding of the domain. > nice REST principle which you may wish to emulate if you can, called HATEOAS. If you can do it, it makes things so much simpler. The basic idea about HATEOAS is the exact inversion of what you are saying: a polymorphic frontend Huh. I'd never really thought of HATEOAS in this way. I've used it before to build an API that can be consumed by another service in a flexible way, but have never really reached for it when building a UI. I guess this would solve the problem by only guaranteeing relationships rather than guaranteeing the full API? This would definitely protect against churn when the structure of the URL's change, but doesn't this still depend on having a solid understanding of the domain from the get-go?