HTTP is for the Old World Internet. The New World Internet (the IoT) is made up of unseen devices that require very little interaction. They consume very little power and frequently have poor network connectivity. HTTP is too heavy to be a good fit for these devices. An HTTP request requires a minimum of nine TCP packets, even more when you consider packet loss from poor connectivity, and plain text headers can get very verbose. And even with all this overhead HTTP doesn't guarantee message delivery!
The HTTP overhead also adds to IoT operating expenses. Current costs of wireless connectivity are exorbitant. My cellphone provider charges $10/GB, and I've seen as much as $1/MB! This is to say nothing of the wireless spectrum shortage . Bandwidth conservation is especially important with enterprise customers that often have hundreds of thousands or millions of devices deployed.
Fortunately there are suitable alternatives to HTTP for communicating with IoT devices.
IoT network traffic falls into two categories: telemetry and telecommand. Telemetry is the act of gathering telemetrics, or sending data over long distances. Usually telemetry involves sending data from many dumb sensors to a smart hub of some sort. The dual of telemetry is telecommand, or the act of sending commands across a network.
Most telemetry protocols are modelled as publish/subscribe architecture. Sensors connect to a broker and periodically publish their readings to a topic. A central cluster of servers (the cloud) will then subscribe to the topic and process sensor readings in real-time. A typical enterprise arrangement will have thousands or millions of sensors sending telemetrics to a handful of servers that split up the task of processing the data.
MQTT (Message Queue Telemetry Transport) is the leading telemetry protocol. It typically runs on top of TCP, adding only a 2-byte header. Usually clients are expected to have poor network connectivity -- either a fault of the wireless technology or because the device