HTTP / REST

What is HTTP/REST in IoT?

HTTP (Hypertext Transfer Protocol) is the foundation of data exchange on the web. In RFID and IoT, it is widely used as the transport for RESTful APIs - interfaces that allow software systems to configure readers, retrieve tag data, and integrate with cloud platforms using the same patterns used across the entire web.

REST (Representational State Transfer) is an architectural style built on HTTP. A RESTful API models resources (such as a reader, a tag read event, or a location zone) as URLs, and uses standard HTTP methods to act on those resources. Because REST is stateless, each request carries all the information needed to process it - there is no session maintained on the server between calls.

In the RFID ecosystem, HTTP/REST is the dominant integration pattern for reader management consoles, cloud RFID platforms, and standards such as EPCIS and GS1 Digital Link.

How it works

HTTP methods

RESTful APIs use four core HTTP methods that map to create, read, update, and delete (CRUD) operations:

• GET: Retrieve a resource. Used to read current reader configuration, query tag read history, or fetch inventory counts. No side effects - safe to call repeatedly.
• POST: Create a new resource or trigger an action. Used to push a tag read event to a cloud platform, create a new filter rule on a reader, or submit an EPCIS event.
• PUT / PATCH: Update an existing resource. Used to change reader transmit power, update antenna configuration, or modify a zone definition. PUT replaces the entire resource; PATCH applies a partial update.
• DELETE: Remove a resource. Used to delete a stored filter, revoke an access credential, or clear a tag read buffer.

Status codes

HTTP responses carry a numeric status code indicating the outcome. Key codes in RFID/IoT contexts:

JSON payloads

RFID and IoT REST APIs almost universally exchange data as JSON (JavaScript Object Notation). A typical tag read event payload sent from a reader or middleware to a cloud platform looks like:

{
  "reader_id": "dock-door-3",
  "timestamp": "2025-06-15T14:23:01.442Z",
  "reads": [
    { "epc": "3034257BF400B7800000162E", "rssi": -62, "antenna": 1 },
    { "epc": "3034257BF400B7800000163A", "rssi": -71, "antenna": 2 }
  ]
}

Webhooks for event notification

Rather than requiring a client to poll repeatedly for new tag reads, many RFID platforms support webhooks - HTTP POST requests pushed from the reader or platform to a user-configured URL whenever an event occurs. The platform becomes the HTTP client; the user's application becomes the server.

Webhooks are the standard mechanism for near-real-time RFID event delivery over HTTP without maintaining a persistent connection. The platform retries the POST if the endpoint returns a non-2xx status, providing basic delivery guarantees.

HTTP in RFID and IoT

Reader configuration APIs

Most enterprise RFID readers expose an HTTP/REST management API for configuration and control. Operations accessible via REST typically include setting transmit power per antenna, enabling or disabling antenna ports, configuring read filters (EPC mask, tag population estimates), starting and stopping the RF field, and retrieving firmware version and hardware status. Readers from vendors such as Zebra, Impinj, and Honeywell all provide REST or HTTP-based management interfaces alongside their native SDKs.

Tag data webhooks

Fixed RFID readers that generate continuous tag read streams often support configurable HTTP endpoints to forward read events. The reader POSTs batches of EPC reads to the configured URL, allowing lightweight cloud ingestion pipelines without requiring the reader to maintain a long-lived MQTT connection or WebSocket session.

Cloud RFID platform integration

Cloud-based RFID and supply chain platforms (including ERP integrations and WMS systems) expose REST APIs for event ingestion and inventory queries. HTTP is the natural integration layer here - it traverses corporate firewalls without special configuration, uses familiar authentication patterns (API keys, OAuth 2.0 bearer tokens), and is supported by every programming language and integration platform.

GS1 Digital Link and EPC lookups

GS1 Digital Link is a standard that encodes GS1 identifiers (GTINs, SSCCs, GLNs) as standard HTTPS URLs. When an RFID tag carries an EPC that maps to a GS1 Digital Link URI, any HTTP client can resolve that URI to retrieve structured product data, authenticity records, or EPCIS event history from a resolver service. This makes HTTP the resolution protocol for the digital product identity layer of supply chain RFID.

HTTPS and TLS security

All production RFID and IoT HTTP communication should use HTTPS - HTTP over TLS - to encrypt data in transit and authenticate the server. Key security patterns in RFID/IoT deployments:

• TLS server authentication: The standard HTTPS model. The client (reader or middleware) verifies the server's certificate against a trusted CA before sending data. Prevents man-in-the-middle attacks on tag read streams being forwarded to cloud endpoints.
• Certificate pinning: The reader or IoT device is configured to accept only a specific server certificate or CA, rather than any certificate trusted by the OS. Protects against attacks using fraudulently issued certificates. Common in high-security RFID deployments such as pharmaceutical serialisation and access control.
• Mutual TLS (mTLS): Both the client and server present certificates. The reader presents its own client certificate to authenticate itself to the server, and the server presents its certificate to authenticate to the reader. mTLS is used when API keys are insufficient - for example, to cryptographically bind a specific reader device to a specific cloud endpoint, preventing unauthorised readers from submitting tag data.
• API keys and OAuth 2.0: Application-level authentication layered on top of TLS. API keys are simple and widely supported. OAuth 2.0 bearer tokens (typically short-lived JWTs) are preferred for integrations with cloud platforms that require scoped access control.

Webhooks vs polling

Two HTTP patterns exist for receiving RFID event data. The right choice depends on latency requirements, infrastructure, and whether the reader or platform can act as an HTTP client:

Advantages

• Universal support: Every programming language, framework, and platform speaks HTTP. No specialist client libraries needed.
• Well-understood: Every developer knows HTTP. Debugging with curl, Postman, or a browser is trivial - far easier than debugging binary protocols.
• Firewall-friendly: HTTP/HTTPS uses standard ports (80/443) that are open in virtually every corporate and cloud network by default.
• Massive tooling ecosystem: API gateways, load balancers, CDNs, reverse proxies, observability tools, and authentication systems are all built around HTTP natively.
• Stateless: Each request is self-contained. No connection state to manage or recover from network interruptions - the client simply retries.
• Standards-based auth: OAuth 2.0, API keys, and mTLS are mature, well-supported, and auditable.
• GS1 alignment: GS1 Digital Link uses HTTPS as its resolution protocol, aligning RFID data with web standards.

Limitations

• Per-request overhead: Each HTTP request carries headers (often hundreds of bytes). For high-frequency tag read streams generating thousands of events per second, this overhead is significant compared to MQTT or WebSocket .
• Not ideal for high-frequency streaming: HTTP request/response is a half-duplex pattern. Continuous bidirectional streaming is not its native mode - WebSockets or MQTT are better suited for sustained high-throughput streams.
• Polling latency: If webhooks are not available, polling introduces inherent latency up to the poll interval. Real-time RFID event detection requires either webhooks or a persistent connection protocol.
• No native pub/sub: HTTP has no built-in publish/subscribe mechanism. Multiple consumers receiving the same RFID event stream requires a message broker or fan-out layer on top of HTTP.
• Constrained device limits: Very low-power IoT devices (microcontrollers with limited RAM) may struggle with TLS handshake overhead. CoAP is designed for this class of device.
• Not suitable for reader-side streaming: Readers generating continuous high-rate tag reads benefit from MQTT's lightweight keep-alive model over HTTP's per-request connection setup cost.

Common applications

• Reader management APIs: Configure transmit power, antenna ports, read filters, and operational mode on enterprise UHF RFID readers via REST.
• Cloud RFID platforms: Platforms such as Zebra SmartCount, Impinj ItemSense, and third-party RFID middleware expose REST APIs for event ingestion and inventory queries.
• EPC data APIs: EPCIS 2.0 defines a REST/JSON binding for querying and submitting supply chain events. HTTP is the transport for EPCIS in modern implementations.
• GS1 Digital Link resolution: HTTPS GET requests to GS1 Digital Link resolvers return structured product data, authenticity records, and event history for tagged items.
• WMS and ERP integration: Warehouse management and ERP systems receive RFID inventory data via REST API calls from RFID middleware, triggering inventory updates and shipment confirmations.
• Tag read webhooks: Fixed readers at dock doors, conveyor belts, and retail fitting rooms POST tag read batches to cloud endpoints in near-real-time.
• Serialisation and authentication services: Pharmaceutical and luxury goods platforms expose REST APIs for tag commissioning, serialisation, and consumer-facing authenticity verification.

HTTP vs MQTT vs WebSocket

Related