Purpose
Devices use HTTPS to call cloud platform REST APIs to report JSON data, easily integrating with Web technology stacks. In intermittent reporting scenarios, short connections can be used each time to avoid maintaining TCP; in high-frequency scenarios, HTTP/2 or MQTT can be considered. TLS certificate chains and clock synchronization are common failure points.
Optimization
Merging reports, compressing payloads, and using session reuse can reduce traffic. Under weak networks, set reasonable timeouts and retry backoff.
Security
OAuth2, device certificates, and mutual TLS are commonly used for identity; preventing replay attacks requires a nonce and timestamp.
API design in cellular scenarios
REST in IoT often faces the problems of 'many requests, large headers, costly TLS handshakes.' This can be mitigated by merging reports, using binary protocols (like CBOR), or a gRPC gateway, but must be compatible with existing cloud platforms. Idempotency keys should be placed in the Header or path to avoid PATCH semantic ambiguity. Pagination and cursors should be stable to prevent duplicate fetching caused by weak network retries. CDNs and edge caching are generally not suitable for device APIs, so pay attention to origin rate limiting and geographic routing.
Observation and version governance
For each device type, record HTTP status code distribution, first-byte delay, and TLS handshake failure reasons, distinguishing certificate issues from ISP hijacking. API version upgrades should maintain a window for old versions and synchronize upgrades in module OTA. Error bodies should include machine-parsable error codes and suggested retry intervals to reduce customer service and on-site troubleshooting costs.
Engineering Practice Supplement
Cross-team collaboration for "HTTP/REST": Hardware provides impedance and power budget, RF provides spurious and sensitivity margins, embedded specifies thread models and storage lifespan, and the cloud specifies SLA and rate limiting. For scenarios like NB-IoT, the business model needs to match wake-up cycles, packet lengths, and downlink capacity; for automotive and mobile scenarios, session retention during handover and roaming must be considered. At project closure, conduct a "red team" style review: verify defined behaviors for weak networks, power loss, certificate expiration, clock jumps, and storage full.
Stateless requests and the cost of a cellular connection
HTTP/REST treats one operation between device and cloud as a stateless request. The method, path, headers, and body express the intent, and the server does not depend on hidden context from the previous connection. An idempotent read, and a create that carries an idempotency key, can be replayed safely. A non-idempotent charge or dispense cannot. For a cellular module, the expensive part is often not the JSON body but DNS, the TCP handshake, and the TLS handshake. Intermittent reports that open a new connection every time spend more bytes and time on the certificate chain and headers than on the telemetry itself. HTTP/2 multiplexing can spread the handshake cost, but both the module stack and the gateway in the middle have to support it. Turning it on only at the server is not enough.
REST fits when interactions are infrequent, the cloud is already a web stack, and one payload fits in one request. When the server must push at any time, or the device stays online to receive commands, short-connection polling multiplies radio wakeups and a long-lived protocol is the better fit. Before use, the device clock must be close enough for the certificate validity window, the APN must be allowed to reach the domain, and a response that is limited by path MTU needs chunking or compression.
Certificate time and the retry window
If the clock is still at the factory default, TLS fails because the certificate is “not yet valid” or “already expired.” A log that only says the handshake failed sends the field team to the antenna. Retries without backoff stack a storm on NAT mappings and server rate limits in a weak network. If the business key lives only in memory, a replay after power loss POSTs the shipment or the charge again. Accepting only HTTP 200, and not parsing the business error code, leaves the device showing “reported” when the channel succeeded and the order was rejected. A certificate chain missing an intermediate certificate is completed by a browser and is not completed by an embedded TLS stack.
Separate a DNS failure from cellular DNS. When a long connection is reclaimed by a middlebox, compare the timeout with NAT and private networks instead of copying a local-network heartbeat. An error response should carry a parseable error code and a suggested time for the next retry. The module sleeps until then, rather than retrying every second.
Design one report so it can be replayed safely. The server recognizes a duplicate by order number or message number, and the device keeps the body locally until it has a clear success. After a timeout, query the status before deciding to send again, rather than POSTing unconditionally. Keep fields that are unrelated to this transaction out of the body, and drop headers that can be dropped. On cellular, every byte occupies radio time. Agree the compression algorithm with the server. Turning it on at one end only cannot be decoded. Certificate rotation needs an overlap: the new certificate is already delivered before the old one expires, so a whole batch does not fail the handshake on the same day. When troubleshooting, separate whether the name resolved, which step the handshake stopped on, and what the business code was. Those three belong to different owners.
Record the status-code distribution and the handshake-failure reason for each device type. Do not store a certificate problem and a server rejection as the same network error. Keep the old path for a while when an interface changes, and switch module firmware and server together. The server puts the retry interval in the error body, and the device sleeps accordingly. Use the encoding both sides agreed. Do not send compressed bytes when compression was not declared.
For short connections, write down how long a cached name resolution stays valid. A resolution failure should not be treated as a radio fault that reboots the module over and over. Read a large response in pieces. Allocating more than the module’s memory at once resets the connection, which looks like the server closed it.