3 ms·
I think you are overstating the difficulty/problem of parsing HTML. The hard part of HTML is actually displaying it.
by shaunxcode 5y ago
I think you are overstating the difficulty/problem of parsing HTML. The hard part of HTML is actually displaying it.
- tannhaeuser 5y ago> HTML parser (one of the most notoriously quirky formats in modern use) Agree with shaunxcode; while HTML indeed has quirks (such as wrt inline script+CSS parsing and URLs), plus overly permissive error recovery, it's just straight SGML with formal tag inference and markup minimization techniques known since at least 1986 when SGML was published. The problem IME with HATEOAS is that even highly capable devs see it as an optional, nice to have feature, when loose coupling and late discovery of links in hypertext is the entire point of Fielding's REST concept. It baffles me to no end that even gifted developers turn to exegetic and "best practice" approaches for justifying their JSON-over-HTTP backends and squeezing invocation parameters into URLs when all they really need is a JSON response that can be parsed by browsers, and often times pass JSON in backend-to-backend responses in non-Javascript environments not even having JSON as built-in serialization format.
- berkes 5y ago> just straight SGML with formal tag inference What's more: the argument against HTML can be made for the soup that is used on the web-for-browsers; where webdevs put divs in spans in a-s in buttons to work around some quirk in CSS or such. This does not go for the HTML that you design especially for an API. Such HTML is simple, clean, lean and flat, while being semantic. Parsing such HTML is easy: every language has a DOM parser for such XML.