4 ms·
In the article I recommend splitting your hypermedia and data APIs up into two separate concerns. The data API can address all of the concerns you have. The h
by recursivedoubts 4y ago
In the article I recommend splitting your hypermedia and data APIs up into two separate concerns.
The data API can address all of the concerns you have.
The hypermedia API, being consumed by an htmx front end, can then take advantage of the strengths of hypermedia (e.g. the uniform interface giving you a lot of flexibility in aggressively refactoring your API.)
Please, read the article.
- sublinear 4y agoThere is no data that should be encapsulated in hypermedia. YAGNI in this sense is the opposite - You Are Gonna Need It
- recursivedoubts 3y agoThat's fine, you can build a reasonable general purpose JSON API very quickly, particularly if you aren't having it dragged around by your web applications nitty-gritty needs. In the linked essay I am riffing on someone already recommending splitting your JSON APIs into a general purpose API for clients, and a specialized one for your web application, in order to separate these two concerns and remove the pressure that that latter puts on the former. I recommend going further with that and adopting hypermedia for your application API, since no one else should be depending on it. I recommend this because I like the hypermedia paradigm, but it only makes sense as part of a complete hypermedia system. Trying to reuse a hypermedia API for other clients isn't a good idea and that's not what I'm recommending. Does that make sense?