1. "use PKI". That's Public Key Infrastructure, what you know as the CA (Certificate Authorities) part of TLS. Basically, keep everything about CAs that you know about now. But rather than using TLS for the connection, you use plain HTTP. The web server would read the content being sent to the client and cryptographically hash it, then sign the hash using the server's certificate, and put this signature in an HTTP header. When the client receives the plaintext, it would look for the header; without it, it can't validate integrity, and could, like, put up a red bar, error page, whatever. By reading the header, and then validating the signature on the hash, and comparing the content to the hash, it can now confirm 1) the content came from the server, and 2) the content is exactly what the server says it's supposed to be. MITM isn't going to happen unless the MITM attacker can create a valid certificate, to use to hash and sign a modified payload with. Integrity verified, content stays plaintext.
2. "use HSTS". HSTS is a crappy hack that browsers use to say "ok, when you first connect to a HTTPS site, if the site tells you this domain should remain HTTPS, then only use HTTPS to connect to it, until a timeout expires". It's similar to SSH's asking you to confirm a host key on first connection. If this dumb hack (which can be defeated if you MITM the first time they connect, or when it expires) is good enough for the web's security with TLS, it's good enough to, say, cache a host key or certificate, if you didn't want to use PKI above. Again, we're just talking about validating the integrity of data, not a full-blown private secure TLS connection, so we don't need the best security in the world (if we did we wouldn't be using HSTS...)
1. "use PKI". That's Public Key Infrastructure, what you know as the CA (Certificate Authorities) part of TLS. Basically, keep everything about CAs that you know about now. But rather than using TLS for the connection, you use plain HTTP. The web server would read the content being sent to the client and cryptographically hash it, then sign the hash using the server's certificate, and put this signature in an HTTP header. When the client receives the plaintext, it would look for the header; without it, it can't validate integrity, and could, like, put up a red bar, error page, whatever. By reading the header, and then validating the signature on the hash, and comparing the content to the hash, it can now confirm 1) the content came from the server, and 2) the content is exactly what the server says it's supposed to be. MITM isn't going to happen unless the MITM attacker can create a valid certificate, to use to hash and sign a modified payload with. Integrity verified, content stays plaintext.
2. "use HSTS". HSTS is a crappy hack that browsers use to say "ok, when you first connect to a HTTPS site, if the site tells you this domain should remain HTTPS, then only use HTTPS to connect to it, until a timeout expires". It's similar to SSH's asking you to confirm a host key on first connection. If this dumb hack (which can be defeated if you MITM the first time they connect, or when it expires) is good enough for the web's security with TLS, it's good enough to, say, cache a host key or certificate, if you didn't want to use PKI above. Again, we're just talking about validating the integrity of data, not a full-blown private secure TLS connection, so we don't need the best security in the world (if we did we wouldn't be using HSTS...)