4 ms·
The comments on this one are worth a read; there are some well thought-out rejections of this. (Like so many of the ranty genre, it's taking a single use-case
by bonaldi 13y ago
The comments on this one are worth a read; there are some well thought-out rejections of this.
(Like so many of the ranty genre, it's taking a single use-case and insisting it covers all cases. Yes, some APIs could be replaced by a negotiated machine-readable version of an HTML page, but other APIs serve specific machine access patterns that don't (and shouldn't) map neatly to the pages humans see.)
- martindale 13y agoCould you give an example of such a pattern?
- bonaldi 13y agoLazy loading is a good one. Perhaps you're letting someone scroll through a list of items, and as they near the bottom you load another 10. What forever-maintained page with a permanent URI does that map to? Even if the API returns just a list of the relevant items, and then you make a separate call to get those objects in your desired representation, there's still a need for the API to serve up the transient bit.
- marcosdumay 13y agoLet's say you put those itens on the /itens?page=5&itens_per_page=10 URL, is there any problem with a site where I type that same URL on my browser and get a HTML page with those same itens, while your Javascript gets JSON? Because that's what the article recommends, and I can't see any reason not to agree with the author. Even more, it would be great to add an "X-Content-Version" header, and get the right version of the API.
- bonaldi 13y agoThere's not a problem, but is there a point? It means creating an essentially useless HTML page. There's expense and overhead to doing it, in both initial dev and maintenance. That expense has to be justified, and what is the justification? "Some guy says you shouldn't have an API, just alternative representations of your HTML, therefore we must have HTML versions of our entire API, even if their content is fully dynamic and doesn't need a permanent static URI". No sale.