> he OSI model was what smart people who thought deeply about the issue decided we should do.
And yet, they came up with 2 layers of stuff that only a limited number of applications actually use (session, presentation), 2 protocols instead of one at layers 2 and 3, a much more complex layer 4 protocol. The application side of network programming would likely be much more difficult if we had used an OSI network instead of TCP/IP.
And yet, when I look at "everything over HTTP" (with occassional divergence to gRPC), it seems like most of it is crudely building missing layers of session and presentation.
Instead of reusing simple common blocks, we have tons of badly written textual parsers mired in historical details of early ASCII teletypes because the ARPA idea of protocol analyser was apparently "connect a teletype".
Many things are done over HTTP not for any particular reason of HTTP features, but because HTTP is the most accepted protocol across secured networks, and the fact that you'll easily find a package for HTTP support in almost any language you care for. HTTP is also the ultimate in portable GUI, so often you'll have an HTTP server for your product anyway, so using any other protocol besides it will add more problems.
If you try to use a new protocol over TCP, you'll quickly find all sorts of corportate networks that will drop your traffic; you'll quickly find that people are reluctant to open several ports to allow both your Web GUI and your backend protocol to talk to each other.
So at a very basic level, people aren't piggybacking over HTTP itself, they are piggy-backing onto "Most Used GUI protocol". It's true that they sometimes adopt some of HTTP's features, especially in terms of caching or common error formats, but much more often they ignore it completely (with WebSockets) or partially (binary data in POST requests with custom error messages).
Just as HATEOAS and Content-Type negotiation are extremely rarely used in application protocols, I don't think a Presentation layer would have ever caught on realistically speaking.
One road not taken could have been to define a rich document format in ASN.1 and write an application to display it, maybe call it something like "a browser".
And yet, they came up with 2 layers of stuff that only a limited number of applications actually use (session, presentation), 2 protocols instead of one at layers 2 and 3, a much more complex layer 4 protocol. The application side of network programming would likely be much more difficult if we had used an OSI network instead of TCP/IP.