RESTful API design for devices in IOT Protocols - Time & Space Complexity
When devices communicate using RESTful APIs, the time it takes to handle requests matters a lot.
We want to know how the processing time grows as more devices or requests come in.
Analyze the time complexity of the following code snippet.
GET /devices
fetch all devices from database
for each device:
fetch device status
return list of devices with status
This code fetches all devices and then gets the status for each device before sending the response.
Identify the loops, recursion, array traversals that repeat.
- Primary operation: Looping through each device to fetch its status.
- How many times: Once for every device in the list.
As the number of devices grows, the time to fetch all statuses grows too.
| Input Size (n) | Approx. Operations |
|---|---|
| 10 | 10 status fetches |
| 100 | 100 status fetches |
| 1000 | 1000 status fetches |
Pattern observation: The work grows directly with the number of devices.
Time Complexity: O(n)
This means if you double the devices, the time to process doubles too.
[X] Wrong: "Fetching all devices and their statuses is always fast regardless of device count."
[OK] Correct: Each device adds extra work, so more devices mean more time needed.
Understanding how request time grows with device count shows you can design APIs that scale well.
"What if the API fetched all device statuses in one batch call instead of one by one? How would the time complexity change?"
Practice
Solution
Step 1: Understand HTTP methods in REST
GET is used to request data without changing it, ideal for reading device info.Step 2: Match method to action
Since retrieving data means reading, GET fits best over POST, PUT, or DELETE.Final Answer:
GET -> Option BQuick Check:
Retrieve data = GET [OK]
- Confusing POST with GET for data retrieval
- Using DELETE to get data
- Thinking PUT retrieves data
Solution
Step 1: Identify RESTful URL structure
RESTful URLs use nouns and hierarchy: resource then ID then sub-resource.Step 2: Check options for correct pattern
/devices/123/settings correctly shows device resource, ID, then settings sub-resource.Final Answer:
/devices/123/settings -> Option DQuick Check:
Resource/ID/sub-resource = /devices/123/settings [OK]
- Placing ID after sub-resource
- Using verbs like 'update' in URL
- Mixing singular and plural resource names
DELETE /devices/456, what is the expected result?Solution
Step 1: Understand DELETE method purpose
DELETE removes the specified resource from the server.Step 2: Apply to device 456
DELETE /devices/456 means remove device with ID 456 from the system.Final Answer:
Remove device 456 from the system -> Option AQuick Check:
DELETE method = remove resource [OK]
- Thinking DELETE retrieves data
- Confusing DELETE with POST or PUT
- Assuming DELETE creates resources
POST /devices/789 but it creates a new device instead. What is the likely mistake?Solution
Step 1: Understand POST vs PUT
POST usually creates new resources; PUT updates existing ones.Step 2: Analyze the API call
POST /devices/789 creates new device; to update, use PUT /devices/789.Final Answer:
Using POST instead of PUT for update -> Option AQuick Check:
Update needs PUT, not POST [OK]
- Using POST for updates
- Confusing GET with POST
- Ignoring HTTP method meaning
Solution
Step 1: Identify batch update needs
To control many devices at once, send a batch request with data.Step 2: Match HTTP method and URL
POST /devices/power with JSON list allows updating multiple devices in one call.Step 3: Evaluate other options
GET fetches data, PUT is per device, DELETE resets devices--none fit batch control well.Final Answer:
POST /devices/power with JSON list of device IDs and states -> Option CQuick Check:
Batch update = POST with data list [OK]
- Using GET to change device states
- Trying PUT for batch updates
- Using DELETE to control power
Ready to prove it?
Pass the test and this pattern moves unknown
