REST APIs for Industrial Automation — Bridging OT and IT

REST APIs (Representational State Transfer Application Programming Interfaces) have become the standard method for integrating industrial automation systems with enterprise IT applications, cloud platforms, and web-based dashboards. They provide a lightweight, HTTP-based integration layer that is familiar to IT developers and increasingly supported by OT vendors.

RESTful Design Patterns for Industrial Data

A well-designed REST API for industrial automation follows consistent resource naming conventions and standard HTTP methods. The core principle is to model industrial assets and processes as resources that can be created, read, updated, and deleted (CRUD).

Resource Naming Conventions

Industrial resources should be named using nouns (not verbs) and organised hierarchically to reflect the plant structure. Common resource patterns include:

• /api/v1/equipment — List all equipment assets. Supports query parameters for filtering by area, type, status.
• /api/v1/equipment/{equipmentId} — Details for a specific equipment item.
• /api/v1/tags/{tagId} — Read a specific process tag's current value and metadata (engineering units, description, data type).
• /api/v1/tags/{tagId}/history?from=2025-01-01T00:00:00Z&to=2025-01-02T00:00:00Z — Retrieve historical values.
• /api/v1/batches/{batchId} — Fetch batch record details, phase execution timeline, and process values.
• /api/v1/alarms — List active alarms. Supports filtering by priority, area, and time range.
• /api/v1/orders/{orderId}/start — POST a command to begin executing a production order.

HTTP Methods and Their Industrial Semantics

• GET — Read-only retrieval of resource state. Safe and idempotent. Example: GET /api/v1/tags/TT-101 returns the current value of temperature tag TT-101.
• POST — Create a new resource or execute a command. Non-idempotent. Example: POST /api/v1/batches creates a new batch; POST /api/v1/equipment/PUMP-101/start issues a start command.
• PUT — Full replacement of a resource. Idempotent. Example: PUT /api/v1/recipes/CHOCOLATE-001 replaces the entire recipe definition.
• PATCH — Partial update of a resource. Example: PATCH /api/v1/tags/TT-101 to update the tag's alarm limits.
• DELETE — Remove a resource. Example: DELETE /api/v1/alarms/12345 to acknowledge and clear an alarm.

URL Structure Best Practices for Industrial APIs

• Versioning — Always use a URL prefix (/api/v1/ or a custom header) to allow the API to evolve without breaking existing clients. Industrial systems have long lifespans — expect APIs to be consumed for 10+ years.
• Filtering and querying — Use standard query parameters: ?status=running, ?area=Reactor-2, ?from=...&to=... for time ranges. For complex filters, consider an OData-compatible syntax.
• Pagination — Use ?page=1&per_page=100 with response headers X-Total-Count and Link for paginated lists. Set reasonable defaults (e.g., 100 items) and maximum limits (e.g., 1000).
• Sorting — Use ?sort=name:asc or ?sort=timestamp:desc for ordered results.

Authentication Methods for Industrial REST APIs

API Keys

API keys are the simplest authentication method: a unique string (e.g., sk_abc123...) passed in the HTTP header (X-API-Key) or as a query parameter. They are well-suited for machine-to-machine communication within a trusted OT network. However, API keys alone provide no identity granularity (all keys have the same permissions unless scoped) and are vulnerable to leakage in logs and URLs. Best practice: use API keys only over HTTPS, rotate them periodically, and restrict them by source IP address.

OAuth 2.0

OAuth 2.0 (RFC 6749) is the industry-standard authorisation framework for REST APIs. In industrial contexts, the Client Credentials Grant is the most common flow: a machine (SCADA historian, MES, edge gateway) authenticates with the authorisation server using its client ID and secret and receives a short-lived access token (typically a JWT — JSON Web Token). The token is included in the Authorization: Bearer <token> header of each API request. The authorisation server validates the token and enforces scope-based permissions (e.g., "read only" vs "read/write"). OAuth 2.0 provides: token expiry and refresh, scoped permissions, and centralised credential management. OPC UA security services (Part 4, OPC 10000-4) define authentication and authorization including OAuth 2.0 integration for industrial use cases.

Mutual TLS (mTLS)

In high-security environments — such as pipeline SCADA, power grid control, or pharmaceutical batch release — mutual TLS provides the highest level of authentication security. Both the client and the server present X.509 certificates during the TLS handshake, ensuring mutual identity verification. mTLS requires a Public Key Infrastructure (PKI) to issue and manage certificates, and is typically used in combination with OAuth 2.0 for authorisation.

Rate Limiting and Data Throttling

Industrial control systems are sensitive to excessive polling — too-frequent API calls can consume network bandwidth, overload historians, or trigger excessive I/O scan cycles on PLCs. Rate limiting protects the server and ensures fair resource allocation:

• Token bucket algorithm — Each client has a "bucket" of tokens that refills at a fixed rate (e.g., 10 tokens per second). Each API request consumes one token. Burst traffic consumes accumulated tokens but is bounded by the bucket size. This allows short bursts while maintaining a sustainable average rate.
• Sliding window algorithm — Counts requests within a rolling time window (e.g., maximum 60 requests per minute). Simpler to implement but permits sharper burst patterns.
• Throttle responses — When a client exceeds the rate limit, the API returns HTTP 429 (Too Many Requests) with a Retry-After header. The response may also include X-RateLimit-Limit, X-RateLimit-Remaining, and X-RateLimit-Reset headers.
• Recommended limits for industrial APIs — Tag reads: 100–1000 requests/minute per client. Tag writes (setpoints): 10–60 requests/minute per client. Command execution: 1–10 requests/minute per client, with idempotency keys to prevent duplicate commands.

Data Format Standards

• JSON (JavaScript Object Notation) — The default format for modern REST APIs. Lightweight, human-readable, and natively parsed by web browsers, Node.js, and Python. Use camelCase field names consistent with industry conventions. Typical response:

{
  "tagName": "FT-101",
  "value": 150.25,
  "unit": "m³/h",
  "quality": "good",
  "timestamp": "2025-03-15T14:30:00.000Z"
}

• XML — Still widely used in ISA-95 / B2MML (Batch Markup Language) integration scenarios. B2MML defines standard XML schemas for production schedules, bill of materials, and performance KPIs exchanged between ERP and MES. XML is more verbose than JSON but provides strict schema validation and is the lingua franca of enterprise integration.
• Protocol Buffers (Protobuf) — Google's binary serialisation format, used for high-throughput, low-latency industrial data exchange. Protobuf messages are 3–10× smaller than equivalent JSON messages and parse 10–100× faster. Used for edge-to-cloud streaming (via gRPC) of high-frequency process data (e.g., vibration analysis at 10 kHz).

Real Integration Example — SCADA to ERP

A practical integration pattern: a SCADA system exposes production counts via a REST API, and the ERP system polls this API to update inventory and production order status:

1. The SCADA system collects actual production counts from PLCs on each packaging line (units produced, rejects, machine status) every minute.
2. A SCADA REST endpoint provides: GET /api/v1/lines/LINE-01/production?from=2025-03-15T06:00:00Z&to=2025-03-15T07:00:00Z. Returns JSON:

{
  "lineId": "LINE-01",
  "periodStart": "2025-03-15T06:00:00Z",
  "periodEnd": "2025-03-15T07:00:00Z",
  "totalGoodCount": 5420,
  "totalRejectCount": 38,
  "lineSpeed": 95.2,
  "status": "running"
}

3. The ERP system's production monitoring module calls this endpoint every 15 minutes via OAuth 2.0 authentication. It compares the production count against the production order target and calculates the projected completion time.
4. If the line status is "stopped" for more than 30 minutes, the ERP sends a notification to the production supervisor via email/SMS and may trigger a manual intervention request.

Error Handling — Consistent Error Responses

A well-designed industrial API returns consistent, structured error responses:

{
  "error": {
    "code": "TAG_NOT_FOUND",
    "message": "The tag 'TT-999' does not exist in the plant model.",
    "status": 404,
    "timestamp": "2025-03-15T14:30:00.000Z",
    "requestId": "req-abc-123"
  }
}

Standard HTTP status codes for industrial APIs:

• 200 OK — Successful GET, PUT, PATCH
• 201 Created — Successful POST (resource created)
• 400 Bad Request — Invalid parameters, malformed JSON
• 401 Unauthorized — Missing or invalid authentication
• 403 Forbidden — Authenticated but insufficient permissions
• 404 Not Found — Resource does not exist
• 409 Conflict — State conflict (e.g., starting a batch that is already running)
• 422 Unprocessable Entity — Semantic error (e.g., setpoint out of range)
• 429 Too Many Requests — Rate limit exceeded
• 500 Internal Server Error — Unexpected server failure
• 503 Service Unavailable — Server temporarily unable to handle request (e.g., historian offline)

ASP OTOMASYON A.Ş. and its subsidiaries OPCTurkey and ASP Dijital provide end-to-end industrial engineering solutions for process automation, data operations and AI.

---

References & Further Reading

1. OAuth 2.0 Authorization Framework — RFC 6749 — Official IETF standard for delegated authorisation, defining the protocol flow, token types, and grant types used in REST API security for industrial applications.
2. OpenAPI Specification 3.1 — Standard for REST API Description — Official OpenAPI specification for describing, producing, consuming, and visualising RESTful web services, widely adopted for industrial API documentation.
3. HTTP/1.1 — Semantics and Content (RFC 7231) — Official IETF specification for HTTP methods, status codes, and request/response semantics fundamental to proper REST API design.
4. ISA-95 / IEC 62264 — Enterprise-Control System Integration — International standard defining the information models and data flows that REST APIs must implement for bridging OT systems with enterprise IT applications.
5. OPC Foundation — REST API Integration Patterns — Official OPC UA documentation on exposing industrial data through RESTful interfaces alongside traditional OPC UA client-server communication.