Application Protocols · Study deck

REST API Practice: Protocol Review

The design rules become real when you have to choose the exact URL, method, status code, and payload for a smart thermostat or offline device.

Broker Bex is your guide for this deck.

rest

Broker Bex, the module guide, in a scene from this chapter.

After studying this chapter

Learning objectives

You will be able to:

Test quiz 2: comprehensive review with a concrete scenario and pass criteria.
Define hands-on exercise: design a smart parking rest api with explicit inputs, errors, and change rules.
'test quiz 2: comprehensive review with a concrete scenario and pass criteria'
'define hands-on exercise: design a smart parking rest api with explicit inputs, errors, and change rules'

Major section

Decision Framework: When to Return 404 vs 503 vs 200 with Stale Data

Scenario: Your IoT REST API receives a request for device data, but the device is offline.

The API request was successful -- we returned valid temperature data.
The client can use the connectivity.status field to decide how to handle staleness.
Device is online but unresponsive (hung firmware).

Major section

Decision Framework: When to Return 404 vs 503 vs 200 with Stale Data (continued)

Mobile apps can display "Last updated 1 hour ago" without treating it as an error.

Offline devices are expected in IoT -- not an error condition.
No cached data available and request requires live data.
Cloud gateway can't reach device network (network partition).
Key principle:: IoT APIs should distinguish between "resource doesn't exist" (404), "resource exists but unavailable" (503), and "resource available but data is stale" (200 with metadata).

Major section

Deep Dive: Reading an HTTP Message Like an Engineer

A REST response is a control signal for firmware, not just a message for a dashboard.

For example, 202 Accepted fits a command queued for a sleeping device, while 204 No Content would falsely imply the action already completed.
Authorization proves who is calling before anything is created.

Major section

Deep Dive: Reading an HTTP Message Like an Engineer (continued)

Returning 500 for a bad client payload makes devices retry a request that can never succeed.

Content-Length must match the actual byte count so parsers can detect truncation or smuggling mistakes.
The two fleet-scale traps are status masking and retry amplification.
That line is the API contract devices actually execute.

Deck summary

Key takeaways

Scenario: Your IoT REST API receives a request for device data, but the device is offline.

Mobile apps can display "Last updated 1 hour ago" without treating it as an error.
A REST response is a control signal for firmware, not just a message for a dashboard.
Returning 500 for a bad client payload makes devices retry a request that can never succeed.

Retrieval practice

Recall check 1 of 4

Broker Bex says: answer from memory, then check your reasoning.

Q1A battery-powered soil moisture sensor wakes every 6 hours, sends a 15-byte reading to a gateway 50 meters away using IEEE 802.15.4 radio (250 kbps max), then immediately sleeps. The sensor's 1000 mAh battery must last 2 years minimum. Gateway then forwards data to cloud using Wi-Fi. Comparing CoAP over UDP vs MQTT over TCP, which protocol saves more battery life and by how much?

AMQTT saves 30% battery - TCP reliability reduces retransmissions

BEqual battery life - both are lightweight IoT protocols

CCoAP saves 40% battery - no TCP handshake, connectionless UDP transmission

DHTTP over TCP saves most battery - mature protocol with better optimization

Show answer

Answer: C see answers page

Retrieval practice

Recall check 2 of 4

Broker Bex says: answer from memory, then check your reasoning.

Q2A smart home system has a phone app that needs to directly query the current temperature from a thermostat and adjust its setpoint. The system also has a cloud dashboard subscribed to temperature updates from 5 thermostats in different rooms for historical logging. Which protocol architecture provides the most efficient solution?

AMQTT for both: Phone publishes setpoint changes, subscribes to temperature; cloud subscribes to all thermostats

BCoAP for phone-thermostat queries; MQTT for thermostats-cloud dashboard (hybrid)

CCoAP for everything: Phone uses GET/PUT, cloud uses Observe for subscriptions

DHTTP REST for phone-thermostat (familiar); MQTT for thermostats-cloud

Show answer

Answer: B

Retrieval practice

Recall check 3 of 4

Broker Bex says: answer from memory, then check your reasoning.

Q3A factory needs real-time (<100ms) alerts from 200 pressure sensors. Network experiences 5% packet loss. Which protocol configuration is BEST?

ACoAP NON messages (non-confirmable) for lowest latency

BCoAP CON messages (confirmable) with retransmission for reliability

CMQTT QoS 2 (exactly-once) for guaranteed delivery

DHTTP polling every 50ms for real-time updates

Show answer

Answer: B CoAP CON messages provide: (1) Reliability with retransmission (handles 5% loss), (2) Low latency — ACK within 20-50ms (meets the <100ms requirement), (3) Minimal overhead.

Retrieval practice

Recall check 4 of 4

Broker Bex says: answer from memory, then check your reasoning.

Q4Calculate total overhead: Sending "25.3" (4 bytes) via CoAP over UDP/IPv4. What percentage is protocol overhead?

A25% - CoAP is very efficient

B50% - Half protocol, half payload

C92% protocol overhead.

D10% - Only CoAP header counts

Show answer

Answer: C Total packet: 4 (payload) + 4 (CoAP) + 8 (UDP) + 20 (IPv4) + 14 (Ethernet) = 50 bytes.

Print reference

Answers 1 of 2

Answer key.

C · This demonstrates protocol overhead impact on battery-powered IoT devices: From the text - Why Lightweight Protocols: "IoT Environment Constraints: - Limited processing power (8-bit to 32-bit microcontrollers) - Constrained memory (KB not GB) - Low bandwidth networks (often < 250 kbps) - Battery-powered operation (months to years) - Unreliable wireless connections" Detailed Power Consumption Analysis: The chapter compares three protocol choices for a sensor that transmits once every 6 hours, using a 1000 mAh battery.
B

Print reference

Answers 2 of 2

Answer key.

B · CoAP CON messages provide: (1) Reliability with retransmission (handles 5% loss), (2) Low latency — ACK within 20-50ms (meets the <100ms requirement), (3) Minimal overhead.
C · Total packet: 4 (payload) + 4 (CoAP) + 8 (UDP) + 20 (IPv4) + 14 (Ethernet) = 50 bytes.