REST API / CRUD – IoT Interface Architect Interview Prep

What is a REST API?

◈ CORE DEFINITION

REST (Representational State Transfer) is an architectural style for building web services. A REST API (Application Programming Interface) exposes backend system data and operations over HTTP using standard methods.

In the IoT/Telecom world, REST APIs are how systems talk: the ordering system calls the billing system, the CRM pushes activations to provisioning, and mediation platforms exchange usage records — all via REST or SOAP/XML endpoints.

6 REST Constraints: Stateless · Client-Server · Cacheable · Uniform Interface · Layered System · Code on Demand (optional)

Stateless = The server stores NO session info. Every request must contain all the context it needs. Critical for scalable telecom APIs with millions of IoT device calls.

CRUD Operations — HTTP Method Mapping

POST CREATE

Creates a new resource on the server. The request body contains the data. The server assigns the ID.

◈ Endpoint: POST /api/devices
◈ Body: JSON payload with resource data
◈ Success response: 201 Created
◈ NOT idempotent — calling twice creates two records
◈ Telecom use: Activate new IoT SIM, create billing account, open service order

GET READ

Retrieves data from the server. No body in request. Safe and idempotent — never changes server state.

◈ Endpoint: GET /api/devices/{id}
◈ Parameters: Path params, query strings
◈ Success response: 200 OK
◈ Idempotent — same result every call
◈ Telecom use: Fetch IoT device status, query subscriber record, retrieve invoice

PUT UPDATE (Full Replace)

Replaces an entire resource. Must send ALL fields even ones not changing. Idempotent.

◈ Endpoint: PUT /api/devices/{id}
◈ Body: Complete resource representation
◈ Success response: 200 OK or 204 No Content
◈ Idempotent — same result if called multiple times
◈ Telecom use: Full service plan update, replace billing profile

PATCH UPDATE (Partial)

Updates only the specified fields. More efficient than PUT — send only what changed.

◈ Endpoint: PATCH /api/devices/{id}
◈ Body: Only the fields being updated
◈ Success response: 200 OK
◈ May or may not be idempotent depending on implementation
◈ Telecom use: Update IoT data plan tier, change device status flag

DELETE DELETE

Removes a resource from the server. Idempotent — deleting something twice returns 404 on the second call, which is acceptable.

◈ Endpoint: DELETE /api/devices/{id}
◈ No request body typically
◈ Success response: 200 OK or 204 No Content
◈ Idempotent in intent
◈ Telecom use: Deactivate IoT device, cancel service order, remove subscriber

HTTP Status Codes You Must Know

200

OK — Request succeeded, data returned

201

Created — POST succeeded, new resource made

204

No Content — Success, nothing to return (DELETE/PUT)

301

Moved Permanently — Endpoint has changed

304

Not Modified — Cached version is still valid

400

Bad Request — Invalid/malformed request body

401

Unauthorized — Authentication required/failed

403

Forbidden — Authenticated but not authorized

404

Not Found — Resource doesn't exist

409

Conflict — Duplicate or version conflict

422

Unprocessable — Schema valid but business rule failed

500

Internal Server Error — Backend crash/bug

502

Bad Gateway — Upstream service returned bad response

503

Service Unavailable — Server overloaded or down

504

Gateway Timeout — Upstream service timed out

REST API Code Examples — Telecom IoT Context

## POST — Create new IoT device subscription (Telecom Ordering API)
## Endpoint: POST /api/v2/iot/devices
## Platform: AT&T IoT Backend · CRM Integration

POST https://api.att.iot.com/v2/devices
Content-Type: application/json
Authorization: Bearer {oauth2_token}
X-Correlation-ID: ORDER-2026-039471

## REQUEST BODY
{
  "iccid": "89014103211118510720",        // SIM card identifier — MANDATORY
  "imei": "358240051111110",            // Device hardware ID — MANDATORY
  "ratePlan": "IOT-1MB-POOLED",         // Billing rate plan — MANDATORY
  "accountId": "ACC-00482910",          // Parent billing account — MANDATORY
  "servicePriority": "STANDARD",      // STANDARD | PREMIUM | CRITICAL
  "activationDate": "2026-03-22",    // ISO 8601 — optional, defaults to today
  "customFields": {
    "fleetId": "FLEET-TX-0047",         // OPTIONAL — customer-defined metadata
    "assetTag": "SENSOR-UNIT-119"
  }
}

## SUCCESS RESPONSE — 201 Created
{
  "deviceId": "DEV-7829341",           // Server-assigned ID — NOTE THIS
  "status": "PROVISIONING",           // PROVISIONING → ACTIVE (async)
  "orderId": "ORD-20260322-4410",      // Fulfillment order reference
  "message": "Device activation initiated"
}

## ERROR RESPONSE — 422 Unprocessable Entity
## Triggered when: iccid already active, invalid rate plan, account suspended
{
  "error": "ICCID_ALREADY_ACTIVE",
  "field": "iccid",
  "code": 42201,
  "message": "SIM 89014103211118510720 is already assigned to account ACC-00480001"
}

## GET — Read IoT device record(s)
## Platform: CRM / Subscriber Management API

## Single resource — path parameter
GET https://api.att.iot.com/v2/devices/DEV-7829341
Authorization: Bearer {oauth2_token}

## Collection with filters — query parameters
GET https://api.att.iot.com/v2/devices?accountId=ACC-00482910&status=ACTIVE&page=1&limit=50

## SUCCESS RESPONSE — 200 OK
{
  "deviceId": "DEV-7829341",
  "iccid": "89014103211118510720",
  "status": "ACTIVE",
  "ratePlan": "IOT-1MB-POOLED",
  "dataUsageMB": 0.72,
  "lastSeen": "2026-03-22T14:30:00Z",
  "billingCycleEnd": "2026-03-31"
}

## INTERVIEW TIP: GET is SAFE + IDEMPOTENT
## Safe     = no side effects, never changes data
## Idempotent = calling 1x or 100x gives same result
## Always use GET for data retrieval — NEVER POST just to read

## PAGINATION PATTERN used in high-volume telecom APIs:
{
  "data": [ /* array of devices */ ],
  "pagination": {
    "total": 48291,
    "page": 1,
    "limit": 50,
    "nextCursor": "eyJpZCI6IjUwIn0="
  }
}

## PUT — Full replace of device record (idempotent)
## MUST send ALL fields or missing fields get nulled

PUT https://api.att.iot.com/v2/devices/DEV-7829341
Content-Type: application/json

{
  "iccid": "89014103211118510720",
  "imei": "358240051111110",
  "ratePlan": "IOT-5MB-POOLED",       // ← Changed from 1MB to 5MB
  "accountId": "ACC-00482910",
  "servicePriority": "PREMIUM",      // ← Upgraded
  "activationDate": "2026-03-22"
  // ALL fields required — omitting = null
}

## Response: 200 OK or 204 No Content

─────────────────────────────────────────
## PATCH — Partial update (only send what changed)
## More common in modern telecom APIs — efficient for IoT at scale

PATCH https://api.att.iot.com/v2/devices/DEV-7829341
Content-Type: application/json

{
  "ratePlan": "IOT-5MB-POOLED",       // Only what changed
  "servicePriority": "PREMIUM"
}

## KEY INTERVIEW POINT — PUT vs PATCH:
## PUT  = replace the whole thing (like overwriting a config file)
## PATCH = update specific fields (like editing one line in a file)
## In telecom billing: PATCH to change rate plan, not PUT
## Wrong method = unintended field nullification = billing errors

## DELETE — Deactivate / remove IoT device
## Platform: AT&T Provisioning / Switch Control Interface

DELETE https://api.att.iot.com/v2/devices/DEV-7829341
Authorization: Bearer {oauth2_token}
X-Reason: CUSTOMER_REQUEST

## SUCCESS: 204 No Content (nothing to return)
## OR: 200 OK with confirmation body
{
  "deviceId": "DEV-7829341",
  "status": "DEACTIVATING",
  "estimatedCompletion": "2026-03-22T15:00:00Z"
}

## SECOND CALL (idempotent check):
## DELETE /v2/devices/DEV-7829341 (again)
## Returns: 404 Not Found — resource already gone — ACCEPTABLE

## TELECOM CRITICAL NOTE:
## Hard delete vs soft delete — most telecom APIs do SOFT DELETE
## status = "DEACTIVATED" in DB, not physically removed
## Why? Billing history, audit trails, SOX compliance
## The DELETE endpoint triggers deactivation workflow in:
##   1. Switch Control / HLR → remove from network
##   2. Billing → prorate final invoice
##   3. CRM → update subscriber record
##   4. Sales Comp → trigger churn credit back

## SOAP vs REST — Critical for AT&T interview (legacy + modern systems)

┌─────────────────┬──────────────────────────┬──────────────────────────┐
│                 │ REST                     │ SOAP                     │
├─────────────────┼──────────────────────────┼──────────────────────────┤
│ Format          │ JSON, XML, any           │ XML only (strict)        │
│ Transport       │ HTTP/HTTPS               │ HTTP, SMTP, TCP          │
│ Contract        │ OpenAPI/Swagger (loose)  │ WSDL (strict schema)     │
│ Error Handling  │ HTTP status codes        │ SOAP Fault envelope      │
│ Security        │ OAuth2, JWT, API Keys    │ WS-Security              │
│ Statefulness    │ Stateless                │ Can be stateful          │
│ Telecom Usage   │ New IoT APIs, microsvcs  │ Legacy BSS/OSS, billing  │
└─────────────────┴──────────────────────────┴──────────────────────────┘

## SOAP Request Example (legacy billing system — still common in AT&T)
<soapenv:Envelope
    xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
    xmlns:bill="http://att.com/billing/v1">
  <soapenv:Header>
    <bill:AuthToken>Bearer eyJh...</bill:AuthToken>
  </soapenv:Header>
  <soapenv:Body>
    <bill:GetInvoiceRequest>
      <bill:AccountId>ACC-00482910</bill:AccountId>
      <bill:BillingPeriod>2026-02</bill:BillingPeriod>
    </bill:GetInvoiceRequest>
  </soapenv:Body>
</soapenv:Envelope>

## INTERVIEW ANSWER for "REST vs SOAP":
## "In my AT&T/TEOCO work, we used both. Legacy billing ran on SOAP/XML
##  interfaces with strict WSDL contracts. New IoT microservices use REST
##  with JSON. The challenge is integration between them — marshaling data
##  across protocol boundaries while preserving field fidelity."

## SCHEMA VALIDATION — Critical for this IoT Interface Architect role
## The job is literally: validate API schemas against business rules

## JSON Schema example — IoT Device activation request
{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "type": "object",
  "required": ["iccid", "imei", "ratePlan", "accountId"],
  "properties": {
    "iccid": {
      "type": "string",
      "pattern": "^[0-9]{19,20}$",      // MANDATORY — 19-20 digit SIM ID
      "description": "SIM card identifier"
    },
    "ratePlan": {
      "type": "string",
      "enum": ["IOT-1MB-POOLED", "IOT-5MB-POOLED", "IOT-UNLIMITED"],
      // MANDATORY with allowed values — billing constraint
    },
    "activationDate": {
      "type": "string",
      "format": "date"          // OPTIONAL — defaults to today in backend
    },
    "customFields": {
      "type": "object"           // OPTIONAL — but this is where hidden deps lurk
    }
  }
}

## HIDDEN DEPENDENCY (the core of this role):
## customFields.fleetId is OPTIONAL in schema
## BUT downstream billing system REQUIRES fleetId for
## corporate accounts with fleet billing enabled
## → Schema says optional → Business logic says mandatory
## → Defect hits in billing, not at API validation
## → This is EXACTLY what the IoT Interface Architect must catch

RESTful Endpoint Design — IoT Device API

Method	Endpoint	Operation	Status Codes	Notes
GET	/v2/devices	List all devices (paginated)	200, 400	Use query params for filters
POST	/v2/devices	Activate new IoT device	201, 400, 409, 422	409 = duplicate ICCID
GET	/v2/devices/{deviceId}	Get single device record	200, 404	Include billing + network status
PUT	/v2/devices/{deviceId}	Full update of device record	200, 400, 404	All fields required
PATCH	/v2/devices/{deviceId}	Change rate plan / status	200, 400, 404, 422	Partial update only
DELETE	/v2/devices/{deviceId}	Deactivate device	204, 404	Soft delete — triggers workflow
GET	/v2/devices/{deviceId}/usage	Get data usage history	200, 404	Sub-resource pattern
POST	/v2/orders	Create service order	201, 400, 422	Ordering system integration

Interview Q&A — Click to Reveal Answers

CORE What is the difference between PUT and PATCH? ▶

PUT replaces the entire resource. You must send ALL fields — any missing field gets set to null. It is idempotent: calling it twice with the same body produces the same result.

PATCH performs a partial update — only the fields you include are modified. More efficient for large objects like subscriber records where you only need to change one field.

Telecom example: A billing profile with 40 fields. Using PUT to change just the rate plan requires sending all 40 fields or risk nulling critical billing data. PATCH sends only {"ratePlan": "IOT-5MB"}.

CORE What does "idempotent" mean and which HTTP methods are idempotent? ▶

An operation is idempotent if calling it once vs. calling it 100 times produces the same outcome on the server.

Idempotent: GET, PUT, DELETE, HEAD, OPTIONS
NOT idempotent: POST (each call creates a new resource)

Why it matters in telecom: If a network timeout causes a retry of a POST activation request, you could accidentally activate the same SIM twice — creating duplicate billing records. This is why ordering systems use idempotency keys: X-Idempotency-Key: ORDER-2026-039471

DESIGN What is the difference between 401 Unauthorized and 403 Forbidden? ▶

401 Unauthorized — The request lacks valid authentication credentials. "I don't know who you are." The client should authenticate and retry. Typically seen when OAuth2 token is missing or expired.

403 Forbidden — Authentication succeeded but the authenticated user lacks permission. "I know who you are, but you can't do this." The client should NOT retry — the request will always be denied.

Telecom example: A service rep authenticated to the CRM (gets past 401) but tries to access billing financial records they don't have RBAC permission for → 403.

TELECOM How do you identify conditional mandatory field issues in an API integration? ▶

This is the core function of the IoT Interface Architect role. The schema may mark a field as optional, but downstream business logic treats it as required under certain conditions.

Approach:
1. Cross-reference the API schema against the actual system's business rule documentation or source code
2. Trace data flows end-to-end: ordering → provisioning → billing → compensation
3. Test all conditional branches — send requests with optional fields missing to see what fails downstream
4. Document contract deviations — "Field X is marked optional in schema but mandatory when account type = CORPORATE"

Real example from AT&T: fleetId optional in schema, mandatory for fleet billing accounts. Schema validation passes at 201, billing rejects at invoice generation → defect found 30 days later during billing cycle.

DESIGN What is REST vs SOAP and when would you use each in telecom? ▶

REST uses HTTP verbs (GET/POST/PUT/DELETE), supports JSON/XML, is lightweight, stateless, and better suited for modern microservices and IoT at scale.

SOAP uses XML envelopes with strict WSDL contracts, supports WS-Security standards, and has formal error handling via SOAP Faults. Still dominant in legacy BSS/OSS telecom systems.

In practice at AT&T/TEOCO: Legacy billing, provisioning, and switch control often run SOAP/XML interfaces (some going back to the 90s). New IoT and CRM layers expose REST. The integration challenge is building adapters that translate between them while preserving field semantics, mandatory/optional logic, and data types.

TRAP ⚠ A POST request returns 200 instead of 201. Is that a problem? ▶

Technically yes, semantically debatable. Per HTTP spec, a successful POST that creates a resource should return 201 Created with a Location header pointing to the new resource.

Returning 200 OK instead of 201 is a common API design error. It means the consumer can't distinguish "this updated something" from "this created something new" just by the status code.

Why it matters in integration: If your middleware or monitoring is keying on 201 to trigger downstream workflows (like provisioning confirmation or billing initiation), getting 200 instead could cause those workflows to not fire — resulting in silent integration failures. This is the type of subtle defect this role is designed to catch.

TELECOM How do you troubleshoot a multi-system integration failure in an IoT order flow? ▶

Step-by-step cross-system debugging approach:

1. Capture the correlation ID — every request should carry a correlation/transaction ID across all hops (X-Correlation-ID header or similar)
2. Establish the failure point — which system returned the error? Check each system's logs with the correlation ID
3. Reproduce in isolation — call the failing system's API directly with the same payload to confirm the error
4. Compare field values — field X in system A may be 20 chars, but system B has a 15-char constraint — data truncation causes silent failures
5. Check conditional field logic — a field that's optional in ordering may be mandatory in billing under certain account types
6. Validate schema vs actual — the published API schema may not match what the production system actually validates

Tools used: Splunk (correlation log search), Postman/curl (direct API calls), SQL queries against CRM/billing tables, Ansible runbooks for remediation

Knowledge Check — Live Quiz

QUESTION 01 / 08

You need to activate a new IoT SIM card in the system. Which HTTP method do you use?

QUESTION 02 / 08

An API call succeeds and creates a new device record. What is the CORRECT HTTP status code to return?

QUESTION 03 / 08

You want to change ONLY the rate plan on an existing IoT device without affecting any other fields. Which method is most appropriate?

QUESTION 04 / 08

A user is authenticated but tries to access a billing record they don't have permission to view. What status code should the API return?

QUESTION 05 / 08

An API schema marks the "fleetId" field as optional. However, the billing system rejects orders without it for corporate accounts. What type of issue is this?

QUESTION 06 / 08

Which HTTP methods are considered IDEMPOTENT? (Pick the best answer)

QUESTION 07 / 08

In REST API design, what does the "stateless" constraint mean?

QUESTION 08 / 08

A SOAP API is used for a legacy AT&T billing system. What format does SOAP always use for messages?

0/8

Interview Readiness Score

← Skills ⌂ Home

REST API & CRUD