Why it matters
Any data platform that has non-JVM consumers eventually needs an HTTP surface on top of HDFS. Data science teams write Python and want a simple requests library call to fetch a file, not a PyArrow-Hadoop integration. Web dashboards want to serve small HDFS files directly to browsers without a middle-tier service. Cross-datacenter transfers over the internet want a firewall-friendly HTTP interface, not the native RPC on obscure ports.
HTTP is also easier to secure, easier to load balance, and easier to log. For clusters where the audit trail matters, funneling reads and writes through a single gateway simplifies compliance dramatically.
The architecture
Native WebHDFS is enabled by a single config flag on every NameNode and DataNode. Once enabled, the NameNode exposes a REST endpoint on its HTTP port (default 9870) that implements all HDFS operations. Reads are handled by redirection: a client asks the NameNode for a file, the NameNode responds with an HTTP redirect pointing to a specific DataNode, and the client follows the redirect and streams bytes from that DataNode. Writes follow a similar redirection pattern.
HttpFS is a separate Tomcat-based service. It runs on any host and speaks the native HDFS RPC to the NameNode and DataNodes on the client's behalf. To the client, HttpFS looks identical to WebHDFS; the URL scheme and API are the same. The difference is that HttpFS terminates all HTTP traffic at itself and never asks the client to redirect to a DataNode.
How it works end to end
A GET on a file with WebHDFS looks like this: the client sends GET to the NameNode with op=OPEN, the NameNode responds with a 307 Temporary Redirect to a DataNode holding a replica, and the client follows the redirect and receives the file body from the DataNode. Two round trips: one metadata, one data.
The same GET with HttpFS is a single connection to the HttpFS gateway. The gateway internally does the NameNode lookup and the DataNode read, then streams bytes back to the client. This is simpler for the client but adds a proxy hop.
Writes are similar. WebHDFS writes require the client to be reachable from every DataNode because the redirect targets DataNode addresses. HttpFS writes involve only the HttpFS gateway.