9.4 HTTP/HTTPS and BLE GATT Interoperability
9.4.1 Where HTTP/HTTPS Fits in IoT
HTTP (HyperText Transfer Protocol) is the most universal application-layer protocol on the Internet, but in IoT scenarios the core question facing engineers is not "is HTTP good or bad" — it is "when to use it, and when to avoid it." Answering it requires first taking the protocol's constraints apart, and then weighing the hard strengths that make it irreplaceable.
Constraints first. HTTP is organized around request-response interactions: the client sends a request, and the server responds. A sensor can perfectly well act as an HTTP client and POST data on a schedule; it needs neither a public address nor a server running on the device. What is unnatural is for the platform to push a message proactively to a device behind NAT when the device has made no request. HTTP/1.1 pipelining and connection reuse have head-of-line blocking problems. HTTP/2 mitigates application-layer blocking with streams and multiplexing, but TCP packet loss still affects streams on the same connection. HTTP/3 uses QUIC instead, further isolating transport blocking between streams. Request-response semantics do not prevent devices from reporting proactively; they simply lack MQTT's built-in publish/subscribe, session, and offline-message semantics.
Transfer efficiency and real-time behavior are no better. Before the first HTTP request can go out, the TCP three-way handshake and a TLS (Transport Layer Security) handshake must complete. For a battery-powered sensor, the energy consumed by each handshake can exceed the energy of transmitting the data itself. Message overhead is far from small: HTTP headers routinely run to hundreds of bytes, carrying User-Agent, Accept, Cookie, and other fields designed for browsers — fields a sensor never uses. CoAP's fixed header is tiny, and its typical request overhead is far below HTTP's; MQTT's fixed header is also very small (a synthesis based on the protocol standards). When a sensor sends a single 8-byte temperature value, HTTP's header overhead is plainly unacceptable. In industrial control that demands millisecond-level response, HTTP's handshake latency and head-of-line blocking can directly slow the production takt — not a design failure of HTTP, but the boundary of where it applies.
Still, HTTP has three hard strengths that IoT engineers cannot get around.
First, ubiquity and ecosystem. Every programming language, operating system, and debugging tool supports HTTP natively. During development, a browser or a single curl command is enough to verify an interface, so the integration threshold is close to zero. RESTful API (Representational State Transfer) design has a complete toolchain (OpenAPI, Swagger), and neither GraphQL nor gRPC escapes HTTP at the bottom of the stack. Device and platform developers share one API contract, cutting communication cost sharply.
Second, a mature security ecosystem. HTTPS is HTTP over TLS, backed by mature cipher suites, certificates, libraries, and operational tools. But "using HTTPS" does not mean security is complete: protocol versions, certificate chains, private-key protection, host identity, rotation, authorization, and application vulnerabilities still have to be verified. Its advantage is the reuse of widely reviewed standard mechanisms, not reducing a security audit to certificate validity alone.
Third, direct linkage to upstream systems. Modern cloud-native architectures, microservices, and web APIs use RESTful interfaces by default. An IoT platform connecting upward to the enterprise's business systems (ERP, MES, CRM) does so naturally over HTTP REST APIs. If the device layer also supports HTTP, the platform needs no additional protocol conversion and saves a layer of proxy overhead. Many industrial protocol-conversion gateways follow exactly this pattern: a Modbus bus on the southbound side, aggregated data reported northbound over HTTP.
On these strengths, HTTP has two typical roles in IoT.
Role 1: Device Provisioning
When a smart bulb or a Wi-Fi camera is used for the first time, the phone app sends the Wi-Fi SSID and password over HTTP to a web server the device opens temporarily. Provisioning is a one-off, user-interactive scenario, insensitive to power consumption — HTTP's ubiquity and convenience are what count. Once provisioning is done, the web server closes automatically.
Role 2: Gateway Northbound Communication
For an edge gateway communicating upward with a platform, HTTP REST APIs are fully adequate when data volume is modest and timing requirements are loose. The gateway has a stable power supply and does not worry about heartbeat overhead; it aggregates data from its child devices and sends it out in batched JSON. In edge-cloud collaboration architectures, HTTP is the most direct means of communication between gateway and platform.
The comparison table below shows how HTTP, MQTT, and CoAP differ across dimensions such as transport layer, message overhead, connection establishment, and typical scenarios.
Table 9-4 HTTP vs MQTT vs CoAP performance comparison (based on IETF protocol standards and general engineering judgment)
| Dimension | HTTP/HTTPS | MQTT | CoAP |
|---|---|---|---|
| Transport protocol | TCP (QUIC/UDP for HTTP/3) | TCP | UDP |
| Communication model | Request/response | Publish/subscribe (broker-relayed) | Request/response (supports the Observe observer pattern) |
| Message overhead | Large (headers of hundreds of bytes) | Minimal (low fixed-header cost) | Minimal (low fixed-header cost; typical requests far below HTTP) |
| Connection setup time | Slow (TCP three-way handshake + TLS handshake) | Medium (long-lived TCP connection kept alive by heartbeats) | Fast (connectionless, plain UDP datagrams) |
| Typical power consumption | High (frequent handshakes) | Medium (heartbeat upkeep cost) | Low |
| Quality of service | No native QoS (relies on TCP retransmission) | QoS 0/1/2 | CON/NON confirmable and non-confirmable messages |
| Device management model | None (must be designed yourself) | None (message delivery only) | None (data exchange only) |
| Typical scenarios | Device provisioning, platform APIs, gateway northbound | Remote monitoring, large-scale device communication | Sensor acquisition, NB-IoT endpoints |
Security and Operational Details of HTTP
HTTPS's security maturity is a general judgment, but on the device side the engineering effort concentrates on certificate lifecycle management. The biggest difference between a device certificate and a browser certificate is this: a browser has a user watching it, and an expiry popup is enough to trigger renewal; an expired device certificate shows up as "device gone silent," and only after on-site troubleshooting does anyone discover the certificate expired — this class of incident accounts for no small share of IoT operations. Device-side HTTPS must therefore design certificate rotation into the lifecycle: the certificate validity period should align with the product replacement cycle (for long-lived devices, rotating once every three years is better than once a year), rotation should complete through a dual-certificate overlap window before the old certificate expires, and the rotation channel itself must not depend on the very certificate about to expire — otherwise you have built a self-lock. The general approach is for the platform to monitor remaining certificate validity and proactively issue rotation commands; at the standards level, the IETF defines EST (Enrollment over Secure Transport) in RFC 7030, under which a device can apply online to the registration authority for a new certificate before the current one expires and complete automatic renewal — but support for EST in embedded TLS stacks is uneven and must be confirmed during selection.
The significance of TLS session resumption for power consumption is often underestimated. A full TLS handshake takes two round trips (TLS 1.3 compresses this to one); for a battery-powered device, every cold-start connection pays this energy bill again. Session resumption mechanisms (Session ID, Session Ticket) let a client skip the full handshake by presenting credentials from the previous session; TLS 1.3's 0-RTT (zero round-trip time) goes further, allowing the very first packet to carry application data. For a sensor that reports ten times a day with eight bytes per report, handshake overhead can account for more than eighty percent of the energy of each communication — session resumption directly determines battery life. But 0-RTT carries replay risk: an attacker who intercepts a 0-RTT packet can resend it, and the server cannot tell the difference. 0-RTT is therefore suitable only for idempotent requests (data reporting is naturally idempotent), not for commands like "unlock the door."
OTA firmware download is one of the few occasions where HTTP is squarely at home on the device side. Firmware images run from hundreds of KB to several MB — ten-thousand-fold the volume of everyday reports — and a transfer of this size needs three things: resumable downloads (HTTP's Range request header supports them natively; after an interruption, transfer resumes from the offset instead of restarting the whole package), large-file distribution (CDN infrastructure is built around HTTP, so firmware can be pushed to edge nodes for nearby download), and verifiable integrity (Content-Length combined with chunked checksums). The reason MQTT is unsuitable for this scenario is equally structural: the publish/subscribe model was designed for small messages; to stuff a multi-MB image into topics as slices, the publisher would have to reinvent, at the application layer, resumable-transfer logic, backpressure control, and slow-consumer isolation — problems HTTP has already solved. The common engineering division of labor: the control plane (notifying the device that new firmware exists) goes over MQTT, while the data plane (downloading the firmware image itself) goes over HTTPS — each used for what it does best.
From Polling to Push: Three Patch Approaches for HTTP
HTTP's request/response model is not good at pushing, but in reality there are always devices that can only speak HTTP (restricted network policies, legacy firmware, outbound-only connectivity). There are three "patch" paths, each buying push capability at a different price.
Short polling: the device periodically sends a GET request to the platform asking "any new commands?" It is the simplest approach, but its latency floor equals the polling interval. Long polling: the platform holds the request until data is available or a timeout expires, after which the device sends the next request. A modern asynchronous server does not need to dedicate one operating-system thread to every connection, but capacity must still be planned around long-lived online connections. Webhook (callback): the platform proactively calls an HTTP interface on the device or gateway; this requires the target to be reliably addressable and its inbound port to be properly protected, so it normally fits managed gateways better. SSE (Server-Sent Events): the server sends events one way over an HTTP connection first established by the client, making it suitable for platform-to-gateway command or event notifications. Gateway-to-platform reporting still requires a separate HTTP request; SSE must not be described as a bidirectional event stream.
The common problem with all three paths is that they are patches on the request/response model. Short polling wastes effort on empty queries; long polling ties up connections; Webhooks require inbound addressability; SSE and Webhooks leave connection keep-alive, reconnection, and event-sequence deduplication to be implemented yourself. MQTT's long-lived connection unifies all of this inside the protocol: heartbeat keep-alive, QoS retransmission, will messages, and session resumption are all standard parts. The engineering conclusion is therefore clear: HTTP push approaches suit gateway-level, low-frequency, retrofit-constrained scenarios; as soon as the device side needs high-frequency proactive reporting or reliable command delivery, return to MQTT/CoAP instead of stacking more patches onto HTTP.
Practical boundary: choosing among HTTP, MQTT, and CoAP requires considering power, message frequency, connection persistence, network reachability, the security design, and platform infrastructure together. Stable power with low-frequency request-response traffic is a reason to evaluate HTTP first; requirements for publish/subscribe, persistent sessions, or low-overhead UDP are reasons to evaluate MQTT or CoAP respectively. Neither battery power nor proactive reporting is by itself an exclusive criterion. AI Agents commonly reach a platform over HTTP, but device-side inference results may use any validated uplink protocol whose delivery semantics fit; they do not have to use MQTT merely to maintain a long-lived connection.
9.4.2 The BLE GATT Protocol and Application-Layer Abstraction
In BLE device development, what determines data-interaction efficiency and deployment quality has never been the Bluetooth radio itself — it is the design of the GATT model. GATT (Generic Attribute Profile) is BLE's application-layer protocol; it defines a set of discovery and access rules for an attribute database. Whether a temperature-humidity sensor's current readings can be read out by a phone app, or a smart lock can report its status on demand, depends on the granularity of the Service, Characteristic, and Descriptor division in GATT and on how permissions are assigned.
GATT's data model is a three-level nested structure: Service, Characteristic, and Descriptor. A BLE device can expose multiple Services — a heart-rate service, a battery-level service, for example. Each Service contains one or more Characteristics — the smallest unit that carries data, whose Value field holds actual values such as temperature or switch state. Each Characteristic declares its permitted operations through the Properties bitmask: Read, Write, Notify (push without acknowledgment), or Indicate (push with acknowledgment). Descriptors provide auxiliary configuration; the most typical is the CCCD (Client Characteristic Configuration Descriptor) — a central device writes to the CCCD to subscribe to that Characteristic's Notify or Indicate messages. Structurally, GATT is in essence not a communication protocol but an access and event-dispatch model for an attribute database; it defines a standardized set of RPC rules.
The figure below shows the main path of the BLE protocol stack from the radio to the application layer, and the key branch between Notification and Indication on the execution path.
Choosing Between Notification and Indication
This is a classic trade-off in BLE engineering. In Notification mode, the device sends data and needs no acknowledgment from the central — energy cost is minimal, a good fit for periodic sensor data such as temperature or heart rate — but packets may be lost when the wireless environment degrades. Indication mode requires every packet to be acknowledged one by one: reliability is high, but latency and power consumption rise noticeably. Both are GATT subprocedures defined by the Bluetooth Core Specification. The engineering advice: use Notification for environmental monitoring and periodic sampling; use Indication for events that must be confirmed, such as command-execution results and fault alarms.
BLE Security: Pairing, Bonding, and Privacy Addresses
GATT itself provides no security; encryption and authentication are handled by the pairing mechanism. BLE has four pairing modes, and the core difference among them is resistance to man-in-the-middle (MITM) attacks. Just Works: the two sides negotiate a key directly without any out-of-band verification and cannot defend against a middleman — an attacker can pair separately with each end and forward plaintext in between. Passkey: the device displays or accepts a six-digit code, and the connection is established only if both sides match; this defends against MITM, but the six-digit keyspace is small, and the device must have display or input capability. Numeric Comparison (introduced with LE Secure Connections): each of the two screens shows a six-digit number and the user confirms the two match; the security rests on "two independent channels" — an attacker cannot make both screens display the same number. Out of Band (OOB): key material is exchanged over a non-Bluetooth channel such as NFC or a QR code; security is highest, and the user experience can be as smooth as "tap to pair."
Bonding is the persistence of keys after pairing: both sides store the negotiated long-term key (LTK) in secure storage, and on reconnection they skip full pairing and encrypt directly — saving both time and energy. The engineering risk lies in where the key is stored: if the LTK sits in readable flash with no secure-boot protection, physical access to the device is enough to extract the key and forge identity, so high-value devices need encryption-acceleration hardware and a secure storage enclave. The resolvable private address (RPA) solves a different problem: BLE addresses are static by default, and anyone with a scanner can track a device's whereabouts over the long term. RPA lets the device rotate to a fresh random address periodically; only a bonded peer holding the corresponding IRK (Identity Resolving Key) can resolve the real identity — reconciling the tension between anti-tracking and identifiability. The engineering advice in summary: devices with screens use Numeric Comparison; screenless but high-value devices use OOB (NFC, factory-provisioned QR codes); Just Works is only for low-value data (sensor readings) and never for lock- or payment-class commands.
BLE Mesh
BLE Mesh extends GATT's point-to-multipoint star topology into a many-to-many relay network. It does not replace GATT; it adds publish/subscribe-based addressing and forwarding on top of it. Every node is both sender and relay, and coverage is guaranteed by controlled flooding. The Mesh Model Layer standardizes behaviors such as lighting control, sensors, and scenes — a developer configures the Generic OnOff model once and can control the on/off state of every related device in the network. In abstraction terms, BLE Mesh lifts the developer from hop-by-hop routing up to operations on semantic models — a direct continuation of the GATT Service/Characteristic paradigm, at coarser granularity and over a more complex topology.
From GATT to Platform Points: BLE Gateway Bridging Patterns
GATT defines the data model for local device interoperation, but the consumer on an IoT platform is not a phone app — it is points and thing models, and a bridge is needed in between. There are two bridging paths. One is the phone-app path: the user's phone acts as a temporary central, reads out GATT data, and reports it to the platform over Wi-Fi — suitable for consumer, human-present scenarios, with the drawback that data continuity depends on the user carrying the device. The other is the BLE gateway path: the gateway acts as a resident central that scans and connects to child devices in batch, converting GATT readings into platform messages — the main path in industrial and building scenarios.
The core of gateway bridging is mapping: one child device's Service/Characteristic combination maps to a device on the platform and its set of points; a Characteristic's UUID and parsing format correspond to the point's property definition (data type, range, unit — echoing the property modeling of the thing model in Chapter 4), and the Properties bitmask determines the point's read/write direction: a Read characteristic maps to a readable point, a Write characteristic to a writable point (command delivery), and a Notify/Indicate characteristic to an event subscription source. At the descriptor level, the CCCD subscription state corresponds to the platform-side configuration item of "is reporting enabled for this point." Once the mapping is done, the southbound BLE details become fully transparent to the platform, and upstream systems see a set of uniformly modeled points.
Two physical-layer parameters define the capacity boundary of the bridge. The connection interval is the polling cycle agreed between the central and the child device: a short interval (say 15 ms) gives high throughput and low latency, but both radios wake frequently and power consumption is high; a long interval (above 1 s) is the reverse. A gateway is usually power-insensitive and pursues throughput, so it can negotiate shorter intervals with child devices; but a single gateway's radio time is a shared resource — the more child devices connected, the less airtime each connection gets, and effective throughput falls as connection count rises. The scanning side is the same: the window and duty cycle of batch scanning determine how quickly new devices are discovered, competing for airtime with data exchange on existing connections. A general engineering rule of thumb is that a single gateway maintaining a dozen or so active connections while polling dozens of low-frequency sensors at minute-level cycles is the comfort zone; high-density scenarios with hundreds of devices call for either stacking gateways with partitioning, or moving directly to BLE Mesh. DC3's BLE driver is one member of the southbound driver family; its capability is positioned as a reference implementation and does not represent the current capability boundary — readers should take the bridging pattern itself as the methodological reference, not the driver's production scale as a selection basis.
In IoT applications, BLE GATT defines the data model for local interoperability among short-range devices. GATT is a common choice for nearby, battery-powered scenarios with a mature phone or gateway ecosystem. Its Service/Characteristic/Descriptor structure and Notification/Indication mechanisms are only part of the engineering foundation; a deployment must also verify connection intervals, MTU, concurrent connections, pairing methods, and vendor interoperability. To sum up this section: HTTP's value lies in its ubiquitous ecosystem and northbound linkage, while BLE GATT's value lies in its short-range local data model. The boundaries of both are jointly determined by power, communication patterns, and security requirements. When device protocols converge at the platform and are exposed to external AI Agents, the question shifts from "which protocol to choose" to "how to expose platform capabilities in a standardized, authorizable manner" — which is exactly what Section 9.5's MCP answers.