HTTP REST for IoT

Quick Cap

HTTP and REST are the backbone of the web, and they are increasingly used in IoT for device provisioning, configuration APIs, OTA update coordination, and cloud integration. REST (Representational State Transfer) is an architectural style -- not a protocol -- built on statelessness, resource-oriented URLs, and standard HTTP methods. For embedded engineers, the key interview challenge is understanding when HTTP/REST is the right choice for IoT (configuration, provisioning, dashboards) versus when it is too heavy (high-frequency telemetry, constrained devices) and MQTT or CoAP is a better fit.

Key Facts:

• REST is an architectural style: Stateless, resource-oriented, uses standard HTTP methods (GET, POST, PUT, DELETE) mapped to CRUD operations
• HTTP overhead is significant: Text headers add 300-800 bytes per request; TCP connection setup adds latency; TLS handshake adds seconds on slow MCUs
• HTTP/2: Binary framing, header compression (HPACK), multiplexing -- reduces overhead but requires TLS and more RAM
• JSON is standard but verbose: CBOR (binary JSON equivalent) is 30-50% smaller and faster to parse on MCUs
• Authentication options: API keys (simplest), JWT (stateless tokens), OAuth 2.0 (delegated authorization), mutual TLS (strongest for device identity)
• Best fit for IoT: On-demand operations (provisioning, OTA metadata, configuration) -- not high-frequency telemetry

Deep Dive

At a Glance

REST Principles

REST is not a protocol -- it is a set of architectural constraints. Understanding these constraints is essential for designing clean APIs and for articulating why REST works well for some IoT scenarios and poorly for others.

HTTP Methods and CRUD Mapping

*PATCH can be made idempotent with proper design, but the spec does not require it.

Idempotency matters in IoT: If a device sends a PUT request to update its configuration but the response is lost (network glitch), the device can safely retry the PUT because applying the same update twice produces the same result. If the device used POST instead, a retry might create a duplicate resource. Design your APIs so that retryable operations use idempotent methods.

Common HTTP status codes for IoT APIs:

HTTP/1.1 vs HTTP/2 for Embedded

For most embedded IoT devices, HTTP/1.1 is the practical choice. HTTP/2's benefits (header compression, multiplexing) matter when making many requests in parallel -- which is typical for web browsers loading dozens of assets, but not for an IoT device making one API call every few minutes. The added complexity and RAM cost of HTTP/2 rarely justify the benefits on constrained devices.

REST API Design for Embedded Devices

Designing APIs that embedded devices will consume requires different considerations than designing for web or mobile clients:

Keep payloads small. A typical REST response for a web app might be 10-50 KB of JSON. An MCU with 64 KB of RAM cannot buffer this. Design endpoints that return only the fields the device needs. Use pagination for lists. Prefer flat JSON structures over deeply nested ones.

Use versioned URLs. Embed the version in the path (/api/v1/...). Devices in the field cannot be updated as easily as web clients. When you release v2 of your API, v1 must continue working for devices that have not received a firmware update.

Design for intermittent connectivity. Devices on cellular or satellite links may have seconds to minutes of connectivity per day. Make endpoints idempotent so retries are safe. Return clear error codes (429, 503) with Retry-After headers so devices know when to try again instead of hammering the server.

Minimize round trips. Every HTTP request on a cellular modem costs power (radio wake-up), time (TCP + TLS handshake), and money (data charges). Batch operations where possible -- one POST with an array of readings is better than 10 individual POSTs.

// Good: batch upload of sensor readings
POST /api/v1/devices/sensor42/readings
Content-Type: application/json

[
  {"type": "temperature", "value": 23.5, "ts": 1700000000},
  {"type": "humidity",    "value": 65.2, "ts": 1700000000},
  {"type": "pressure",   "value": 1013, "ts": 1700000000}
]

JSON vs CBOR

Practical recommendation: Use JSON for APIs that humans will debug and web clients will consume. Use CBOR on constrained device-to-device or device-to-gateway links where bandwidth is precious. Many IoT architectures use CBOR between sensor and gateway, then the gateway translates to JSON for the cloud API.

Authentication for IoT REST APIs

The embedded trade-off: API keys are the simplest to implement -- the device includes X-API-Key: abc123 in every request. But if the key is compromised (extracted from firmware), all devices using that key are compromised. Per-device API keys or mutual TLS (where each device has a unique certificate) are more secure but harder to provision. JWT is a good middle ground: the device authenticates once (with a certificate or credentials), receives a time-limited token, and includes it in subsequent requests.

TLS/HTTPS Overhead on Constrained Devices

HTTPS (HTTP over TLS) is essential for security, but the costs are significant on MCUs:

Strategies to reduce TLS overhead on constrained devices:

• Use ECC certificates (ECDSA P-256) instead of RSA -- smaller keys, faster handshake, less RAM
• Enable TLS session resumption so reconnections skip the full handshake
• Use TLS 1.3 (fewer round trips, mandatory forward secrecy, smaller handshake)
• Offload TLS to a hardware crypto accelerator (many MCUs have AES, SHA, and ECC hardware)
• If TLS is truly impossible on the MCU, terminate TLS at a gateway and use a physically secured link between the MCU and gateway

When REST is Appropriate for IoT (and When It Is Not)

This is the critical trade-off question in interviews.

The rule of thumb: Use HTTP/REST for the control plane (provisioning, configuration, OTA coordination, monitoring dashboards) and MQTT or CoAP for the data plane (telemetry, events, real-time commands). Many production IoT systems use both -- the device talks MQTT for telemetry and receives configuration via HTTP REST endpoints.

Embedded HTTP Clients

For embedded Linux (Yocto, Buildroot): libcurl is the standard choice. It handles connection pooling, TLS, redirects, and retries. The downside is memory footprint -- it is a full-featured library designed for general-purpose computing.

For bare-metal/RTOS: Most developers use the HTTP client built into their SDK (ESP-IDF, Zephyr, STM32 LwIP). For custom implementations, mongoose provides a single-file HTTP server and client that is easy to integrate.

Debugging Story: The 30-Second OTA Timeout

An IoT gateway running embedded Linux downloaded OTA firmware updates via HTTPS from an S3-compatible cloud storage service. The update process worked reliably in the lab but failed intermittently in the field -- the download would start, transfer 200-300 KB, then stall and eventually time out after 30 seconds with a "connection reset" error.

The lab used a wired Ethernet connection with 50 ms latency and no packet loss. The field devices used LTE-M cellular with 200-500 ms latency and occasional 2-5% packet loss. Investigation revealed two overlapping issues:

First, the HTTP client (libcurl) was configured with a 30-second inactivity timeout (CURLOPT_LOW_SPEED_TIME). On the cellular link, TCP congestion control reacted to packet loss by reducing the window dramatically. After a burst of loss, the TCP window shrank to the point where data transfer slowed below the minimum speed threshold, triggering the timeout. The fix was increasing the timeout to 120 seconds and lowering the minimum speed threshold to 100 bytes/sec.

Second, the cellular modem's TCP window was limited to 16 KB. With a 500 ms RTT, this capped throughput at 32 KB/s regardless of available bandwidth. The 2 MB firmware update took over 60 seconds at best, and any congestion-related slowdown pushed it past the timeout. The fix was enabling TCP window scaling on the modem and increasing the window to 64 KB.

Lesson: HTTP over cellular is fundamentally different from HTTP over Ethernet. TCP congestion control interacts with high-latency, lossy links in ways that desktop developers never encounter. Always test OTA downloads under realistic network conditions (high latency, packet loss, variable bandwidth) and configure timeouts that accommodate the worst-case cellular behavior -- not the best-case lab conditions.

CoAP: REST over UDP for Constrained Devices

CoAP (Constrained Application Protocol, RFC 7252) brings the REST model to devices too constrained for HTTP. It maps GET, PUT, POST, and DELETE to compact binary messages that travel over UDP instead of TCP -- eliminating the connection setup, congestion control overhead, and per-connection RAM that make HTTP impractical on the smallest MCUs. CoAP headers are just 4 bytes (versus hundreds of bytes for HTTP headers), and the entire protocol can run in under 10 KB of RAM. It is the protocol underneath LwM2M (the OMA device management standard) and pairs naturally with CBOR for payload encoding and DTLS for security.

CoAP vs HTTP -- key differences:

CoAP defines two message types for reliability control. CON (Confirmable) messages require an ACK from the receiver -- if no ACK arrives, CoAP retransmits with exponential backoff (similar to TCP but at the application layer, with far less state). NON (Non-confirmable) messages are fire-and-forget, like UDP itself -- ideal for periodic sensor readings where the next value replaces the last. This per-message reliability choice gives embedded developers fine-grained control that TCP's all-or-nothing reliability cannot provide. A single device can send critical alerts as CON and routine telemetry as NON, optimizing battery life without giving up reliability where it matters.

The Observe pattern is CoAP's answer to HTTP polling. A client sends a GET request with an Observe option registered. The server then pushes notifications whenever the resource changes -- without the client polling repeatedly. This is transformative for battery-powered sensors: instead of a monitoring dashboard polling 100 sensors every 5 seconds (100 request-response round trips), the sensors push updates only when values change. On a 6LoWPAN mesh network where every packet costs radio time and battery, Observe can reduce traffic by 90% or more compared to HTTP polling.

In practice, CoAP is most commonly deployed on IEEE 802.15.4 / 6LoWPAN / Thread networks where IPv6 packets are compressed to fit in 127-byte radio frames and every byte of protocol overhead matters. A CoAP-to-HTTP proxy at the border router translates between the constrained network and standard REST infrastructure, letting cloud services consume sensor data via normal HTTP while the sensors themselves use CoAP's minimal footprint. Libraries like libcoap, microcoap, and Zephyr's CoAP subsystem provide lightweight implementations for Cortex-M targets, typically requiring 5-15 KB of flash and 2-5 KB of RAM.

What interviewers want to hear: You understand REST principles (statelessness, resources, uniform interface) and can explain why they matter for IoT API design. You can map CRUD to HTTP methods and explain idempotency. You know HTTP/1.1 vs HTTP/2 trade-offs with embedded context. You can compare JSON and CBOR for constrained devices. You understand authentication options (API keys, JWT, mTLS) and their embedded trade-offs. Critically, you know when REST is the right choice (control plane: provisioning, configuration, OTA) and when it is too heavy (data plane: telemetry, events) -- and you can articulate this trade-off with concrete reasoning about header size, connection overhead, power consumption, and server push capability.

Interview Focus

Classic HTTP/REST Interview Questions

Q1: "What are the core REST principles, and why does statelessness matter for IoT?"

Model Answer Starter: "REST is built on statelessness, resource orientation, a uniform interface (standard HTTP methods), and representations. Statelessness means every request contains all information needed to process it -- the server stores no per-client session state. This matters for IoT because it enables horizontal scaling: when 100,000 devices are calling your API, any backend server can handle any request without needing session affinity. It also simplifies device firmware -- the device does not need to track session state or handle session expiry. The trade-off is that every request must include authentication credentials, which adds per-request overhead."

Q2: "When would you use HTTP/REST for an IoT device versus MQTT?"

Model Answer Starter: "I use HTTP/REST for the control plane -- device provisioning, configuration retrieval, OTA update manifest download, and any interaction where standard web tooling and caching are valuable. HTTP is request/response and stateless, which maps naturally to read-config-then-apply operations. I use MQTT for the data plane -- continuous telemetry, event notifications, and real-time commands -- because MQTT's persistent TCP connection, 2-byte header, and pub/sub model are dramatically more efficient for high-frequency, bidirectional data flow. Many production systems use both: the device fetches its configuration via HTTPS on boot, then opens an MQTT connection for ongoing telemetry and commands."

Q3: "How does TLS impact an embedded device, and how would you reduce its overhead?"

Model Answer Starter: "TLS adds 20-40 KB of RAM for session state and certificate buffers, 50-100 KB of flash for the library, and 1-5 seconds for the handshake on a Cortex-M4. I reduce this by using ECC certificates instead of RSA (smaller keys, faster math), enabling TLS session resumption so reconnections skip the full handshake, using TLS 1.3 which has fewer round trips, and offloading crypto to hardware accelerators (many MCUs have AES and SHA peripherals). If the device is too constrained for TLS, I terminate TLS at a gateway and secure the MCU-to-gateway link physically or with a lightweight symmetric cipher."

Q4: "What is the difference between JSON and CBOR, and when would you use each?"

Model Answer Starter: "JSON is text-based, human-readable, and universally supported by cloud services and web tools. CBOR is a binary encoding that is semantically equivalent to JSON but 30-50% smaller and faster to parse because it uses tag-length-value encoding instead of text tokenization. I use JSON for APIs that humans debug frequently and that web clients consume. I use CBOR on constrained device-to-gateway links where bandwidth is limited and every byte counts -- for example, sensor readings sent over NB-IoT where data costs money per byte. Many architectures translate CBOR to JSON at the gateway."

Q5: "How would you design a REST API for an IoT device fleet?"

Model Answer Starter: "I would version the API in the URL path (/api/v1/...) because field devices cannot be updated as easily as web clients. Resources map to IoT entities: /api/v1/devices/{id} for device info, /api/v1/devices/{id}/config for configuration, /api/v1/devices/{id}/firmware for OTA. I would use PUT for configuration updates (idempotent, safe to retry), POST for telemetry data submission (creates a new reading), and GET for status checks. Payloads would be compact JSON with only necessary fields. I would return proper status codes -- 429 with Retry-After for rate limiting, 503 for maintenance -- so devices implement exponential backoff rather than hammering the server. For authentication, I would use per-device API keys for simplicity or mutual TLS for stronger identity."

Trap Alerts

• Don't say: "Just use HTTP for everything in IoT." HTTP's text headers, TCP connection overhead, and client-pull model make it a poor choice for high-frequency telemetry or real-time commands. Knowing when NOT to use HTTP is as important as knowing how to use it.
• Don't forget: Idempotency. IoT devices operate on unreliable networks and will retry requests. If your API uses POST for an operation that should be idempotent (like updating configuration), a retry creates a duplicate. Use PUT or PATCH for updates.
• Don't ignore: TLS overhead. Saying "just add HTTPS" without acknowledging the RAM, flash, and CPU cost shows you have not worked on constrained devices. An MCU with 64 KB RAM may not have room for both TLS and the application.

Follow-up Questions

• "How would you handle OTA firmware updates over HTTP for a fleet of 10,000 devices?"
• "What is the difference between HTTP keep-alive and a persistent MQTT connection?"
• "How would you implement rate limiting on an IoT REST API?"
• "What is content negotiation in HTTP, and how would you use it to serve both JSON and CBOR from the same endpoint?"

Practice

Real-World Tie-In

OTA Update Coordination -- A fleet of 50,000 smart thermostats used HTTPS REST to check for firmware updates. Each device called GET /api/v1/devices/{id}/firmware/latest on boot and once daily, receiving a JSON manifest with the firmware version, SHA-256 checksum, and download URL. If a new version was available, the device downloaded the binary from a CDN via HTTPS. The REST API served the manifest (1 KB) cheaply, while the CDN handled the bulk transfer. Using REST for the metadata and CDN for the binary kept the API server's load manageable across 50,000 devices.

Hybrid MQTT plus REST Architecture -- An industrial IoT platform used MQTT for continuous machine telemetry (vibration, temperature, power consumption at 1 Hz) and REST for the management plane. Operators used a web dashboard that called REST endpoints to query device status (GET /api/v1/machines/{id}), update alert thresholds (PUT /api/v1/machines/{id}/config), and trigger diagnostics (POST /api/v1/machines/{id}/diagnostics). The gateway translated between MQTT on the factory floor and REST for the cloud. This separation kept the data plane efficient (MQTT's 2-byte header, persistent connection) while giving the management plane the benefits of standard HTTP tooling, caching, and browser compatibility.

Cellular Asset Tracker with Batch Upload -- A logistics company deployed LTE-M GPS trackers on shipping containers. Each tracker accumulated 24 hours of GPS readings (latitude, longitude, timestamp) in flash memory, then connected once per day via cellular and uploaded all readings in a single POST /api/v1/trackers/{id}/positions request with a JSON array. Batching was critical: each cellular connection cost 5 seconds of radio time (TCP + TLS handshake) and data charges per KB. Sending one request with 288 readings (one per 5 minutes) cost the same connection overhead as sending 288 individual requests but used 1/288th of the radio wake-ups.