{"data":{"slug":"rest-apis-for-industrial-automation","title":"REST APIs for Industrial Automation — Bridging OT and IT","summary":"REST APIs (Representational State Transfer Application Programming Interfaces) have become the standard method for integrating industrial automation systems…","category":{"slug":"modern-connectivity","name":"Modern Connectivity"},"url":"https://wiki.aspotomasyon.com/article/rest-apis-for-industrial-automation","markdown_url":"https://wiki.aspotomasyon.com/article/rest-apis-for-industrial-automation.md","api_url":"https://wiki.aspotomasyon.com/api/v1/articles/rest-apis-for-industrial-automation","published":"2026-05-13T11:58:29+00:00","modified":"2026-09-13T11:07:23+00:00","reading_minutes":8,"word_count":1562,"image":"https://wiki.aspotomasyon.com/assets/social/rest-apis-for-industrial-automation-08df1b5c206b.png","html":"<p><strong>REST APIs</strong> (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.</p><figure class=\"article-figure\"><img src=\"https://wiki.aspotomasyon.com/assets/diagrams/modern-connectivity-context.svg\" width=\"1100\" height=\"460\" loading=\"lazy\" decoding=\"async\" alt=\"A generic industrial messaging path. A network or broker acknowledgment is not necessarily confirmation that a downstream business action succeeded.\"><figcaption>A generic industrial messaging path. A network or broker acknowledgment is not necessarily confirmation that a downstream business action succeeded. <a href=\"https://wiki.aspotomasyon.com/assets/diagrams/modern-connectivity-context.svg\" target=\"_blank\" rel=\"noopener\">View full size</a></figcaption></figure>\n\n<hr>\n<h2 id=\"restful-design-patterns-for-industrial-data\">RESTful Design Patterns for Industrial Data</h2>\n<p>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).</p>\n\n<h3 id=\"resource-naming-conventions\">Resource Naming Conventions</h3>\n<p>Industrial resources should be named using nouns (not verbs) and organised hierarchically to reflect the plant structure. Common resource patterns include:</p>\n<ul>\n    <li><code translate=\"no\" class=\"notranslate\">/api/v1/equipment</code> — List all equipment assets. Supports query parameters for filtering by area, type, status.</li>\n    <li><code translate=\"no\" class=\"notranslate\">/api/v1/equipment/{equipmentId}</code> — Details for a specific equipment item.</li>\n    <li><code translate=\"no\" class=\"notranslate\">/api/v1/tags/{tagId}</code> — Read a specific process tag's current value and metadata (engineering units, description, data type).</li>\n    <li><code translate=\"no\" class=\"notranslate\">/api/v1/tags/{tagId}/history?from=2025-01-01T00:00:00Z&amp;to=2025-01-02T00:00:00Z</code> — Retrieve historical values.</li>\n    <li><code translate=\"no\" class=\"notranslate\">/api/v1/batches/{batchId}</code> — Fetch batch record details, phase execution timeline, and process values.</li>\n    <li><code translate=\"no\" class=\"notranslate\">/api/v1/alarms</code> — List active alarms. Supports filtering by priority, area, and time range.</li>\n    <li><code translate=\"no\" class=\"notranslate\">/api/v1/orders/{orderId}/start</code> — POST a command to begin executing a production order.</li>\n</ul>\n\n<h3 id=\"http-methods-and-their-industrial-semantics\">HTTP Methods and Their Industrial Semantics</h3>\n<ul>\n    <li><strong>GET</strong> — Read-only retrieval of resource state. Safe and idempotent. Example: <code translate=\"no\" class=\"notranslate\">GET /api/v1/tags/TT-101</code> returns the current value of temperature tag TT-101.</li>\n    <li><strong>POST</strong> — Create a new resource or execute a command. Non-idempotent. Example: <code translate=\"no\" class=\"notranslate\">POST /api/v1/batches</code> creates a new batch; <code translate=\"no\" class=\"notranslate\">POST /api/v1/equipment/PUMP-101/start</code> issues a start command.</li>\n    <li><strong>PUT</strong> — Full replacement of a resource. Idempotent. Example: <code translate=\"no\" class=\"notranslate\">PUT /api/v1/recipes/CHOCOLATE-001</code> replaces the entire recipe definition.</li>\n    <li><strong>PATCH</strong> — Partial update of a resource. Example: <code translate=\"no\" class=\"notranslate\">PATCH /api/v1/tags/TT-101</code> to update the tag's alarm limits.</li>\n    <li><strong>DELETE</strong> — Remove a resource. Example: <code translate=\"no\" class=\"notranslate\">DELETE /api/v1/alarms/12345</code> to acknowledge and clear an alarm.</li>\n</ul>\n\n<h3 id=\"url-structure-best-practices-for-industrial-apis\">URL Structure Best Practices for Industrial APIs</h3>\n<ul>\n    <li><strong>Versioning</strong> — Always use a URL prefix (<code translate=\"no\" class=\"notranslate\">/api/v1/</code> 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.</li>\n    <li><strong>Filtering and querying</strong> — Use standard query parameters: <code translate=\"no\" class=\"notranslate\">?status=running</code>, <code translate=\"no\" class=\"notranslate\">?area=Reactor-2</code>, <code translate=\"no\" class=\"notranslate\">?from=...&amp;to=...</code> for time ranges. For complex filters, consider an OData-compatible syntax.</li>\n    <li><strong>Pagination</strong> — Use <code translate=\"no\" class=\"notranslate\">?page=1&amp;per_page=100</code> with response headers <code translate=\"no\" class=\"notranslate\">X-Total-Count</code> and <code translate=\"no\" class=\"notranslate\">Link</code> for paginated lists. Set reasonable defaults (e.g., 100 items) and maximum limits (e.g., 1000).</li>\n    <li><strong>Sorting</strong> — Use <code translate=\"no\" class=\"notranslate\">?sort=name:asc</code> or <code translate=\"no\" class=\"notranslate\">?sort=timestamp:desc</code> for ordered results.</li>\n</ul>\n\n<h2 id=\"authentication-methods-for-industrial-rest-apis\">Authentication Methods for Industrial REST APIs</h2>\n\n<h3 id=\"api-keys\">API Keys</h3>\n<p>API keys are the simplest authentication method: a unique string (e.g., <code translate=\"no\" class=\"notranslate\">sk_abc123...</code>) passed in the HTTP header (<code translate=\"no\" class=\"notranslate\">X-API-Key</code>) 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.</p>\n\n<h3 id=\"oauth-20\">OAuth 2.0</h3>\n<p><strong>OAuth 2.0</strong> (RFC 6749) is the industry-standard authorisation framework for REST APIs. In industrial contexts, the <strong>Client Credentials Grant</strong> 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 <code translate=\"no\" class=\"notranslate\">Authorization: Bearer &lt;token&gt;</code> 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.</p>\n\n<h3 id=\"mutual-tls-mtls\">Mutual TLS (mTLS)</h3>\n<p>In high-security environments — such as pipeline SCADA, power grid control, or pharmaceutical batch release — <strong>mutual TLS</strong> 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.</p>\n\n<h2 id=\"rate-limiting-and-data-throttling\">Rate Limiting and Data Throttling</h2>\n<p>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:</p>\n<ul>\n    <li><strong>Token bucket algorithm</strong> — 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.</li>\n    <li><strong>Sliding window algorithm</strong> — Counts requests within a rolling time window (e.g., maximum 60 requests per minute). Simpler to implement but permits sharper burst patterns.</li>\n    <li><strong>Throttle responses</strong> — When a client exceeds the rate limit, the API returns HTTP 429 (Too Many Requests) with a <code translate=\"no\" class=\"notranslate\">Retry-After</code> header. The response may also include <code translate=\"no\" class=\"notranslate\">X-RateLimit-Limit</code>, <code translate=\"no\" class=\"notranslate\">X-RateLimit-Remaining</code>, and <code translate=\"no\" class=\"notranslate\">X-RateLimit-Reset</code> headers.</li>\n    <li><strong>Recommended limits for industrial APIs</strong> — 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.</li>\n</ul>\n\n<h2 id=\"data-format-standards\">Data Format Standards</h2>\n<ul>\n    <li><strong>JSON</strong> (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:</li>\n</ul>\n<pre translate=\"no\" class=\"notranslate\">{\n  \"tagName\": \"FT-101\",\n  \"value\": 150.25,\n  \"unit\": \"m³/h\",\n  \"quality\": \"good\",\n  \"timestamp\": \"2025-03-15T14:30:00.000Z\"\n}</pre>\n<ul>\n    <li><strong>XML</strong> — 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.</li>\n    <li><strong>Protocol Buffers (Protobuf)</strong> — 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).</li>\n</ul>\n\n<h2 id=\"real-integration-example-scada-to-erp\">Real Integration Example — SCADA to ERP</h2>\n<p>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:</p>\n<ol>\n    <li>The SCADA system collects actual production counts from PLCs on each packaging line (units produced, rejects, machine status) every minute.</li>\n    <li>A SCADA REST endpoint provides: <code translate=\"no\" class=\"notranslate\">GET /api/v1/lines/LINE-01/production?from=2025-03-15T06:00:00Z&amp;to=2025-03-15T07:00:00Z</code>. Returns JSON:</li>\n</ol>\n<pre translate=\"no\" class=\"notranslate\">{\n  \"lineId\": \"LINE-01\",\n  \"periodStart\": \"2025-03-15T06:00:00Z\",\n  \"periodEnd\": \"2025-03-15T07:00:00Z\",\n  \"totalGoodCount\": 5420,\n  \"totalRejectCount\": 38,\n  \"lineSpeed\": 95.2,\n  \"status\": \"running\"\n}</pre>\n<ol start=\"3\">\n    <li>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.</li>\n    <li>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.</li>\n</ol>\n\n<h2 id=\"error-handling-consistent-error-responses\">Error Handling — Consistent Error Responses</h2>\n<p>A well-designed industrial API returns consistent, structured error responses:</p>\n<pre translate=\"no\" class=\"notranslate\">{\n  \"error\": {\n    \"code\": \"TAG_NOT_FOUND\",\n    \"message\": \"The tag 'TT-999' does not exist in the plant model.\",\n    \"status\": 404,\n    \"timestamp\": \"2025-03-15T14:30:00.000Z\",\n    \"requestId\": \"req-abc-123\"\n  }\n}</pre>\n<p>Standard HTTP status codes for industrial APIs:</p>\n<ul>\n    <li><strong>200 OK</strong> — Successful GET, PUT, PATCH</li>\n    <li><strong>201 Created</strong> — Successful POST (resource created)</li>\n    <li><strong>400 Bad Request</strong> — Invalid parameters, malformed JSON</li>\n    <li><strong>401 Unauthorized</strong> — Missing or invalid authentication</li>\n    <li><strong>403 Forbidden</strong> — Authenticated but insufficient permissions</li>\n    <li><strong>404 Not Found</strong> — Resource does not exist</li>\n    <li><strong>409 Conflict</strong> — State conflict (e.g., starting a batch that is already running)</li>\n    <li><strong>422 Unprocessable Entity</strong> — Semantic error (e.g., setpoint out of range)</li>\n    <li><strong>429 Too Many Requests</strong> — Rate limit exceeded</li>\n    <li><strong>500 Internal Server Error</strong> — Unexpected server failure</li>\n    <li><strong>503 Service Unavailable</strong> — Server temporarily unable to handle request (e.g., historian offline)</li>\n</ul>\n<blockquote>\n<p>ASP OTOMASYON A.Ş. and its subsidiaries OPCTurkey and ASP Dijital provide end-to-end industrial engineering solutions for process automation, data operations and AI.</p></blockquote><hr>\n<h2 id=\"references-further-reading\">References &amp; Further Reading</h2>\n<ol>\n    <li><a href=\"https://oauth.net/2/\" rel=\"noopener noreferrer\" target=\"_blank\">OAuth 2.0 Authorization Framework — RFC 6749</a> — Official IETF standard for delegated authorisation, defining the protocol flow, token types, and grant types used in REST API security for industrial applications.</li>\n    <li><a href=\"https://spec.openapis.org/oas/v3.1.0\" rel=\"noopener noreferrer\" target=\"_blank\">OpenAPI Specification 3.1 — Standard for REST API Description</a> — Official OpenAPI specification for describing, producing, consuming, and visualising RESTful web services, widely adopted for industrial API documentation.</li>\n    <li><a href=\"https://www.ietf.org/rfc/rfc7231.txt\" rel=\"noopener noreferrer\" target=\"_blank\">HTTP/1.1 — Semantics and Content (RFC 7231)</a> — Official IETF specification for HTTP methods, status codes, and request/response semantics fundamental to proper REST API design.</li>\n    <li><a href=\"https://www.isa.org/standards-and-publications/isa-standards/isa-95-standard\" rel=\"noopener noreferrer\" target=\"_blank\">ISA-95 / IEC 62264 — Enterprise-Control System Integration</a> — International standard defining the information models and data flows that REST APIs must implement for bridging OT systems with enterprise IT applications.</li>\n    <li><a href=\"https://reference.opcfoundation.org/specs/OPC-10000-1\" rel=\"noopener noreferrer\" target=\"_blank\">OPC Foundation — REST API Integration Patterns</a> — Official OPC UA documentation on exposing industrial data through RESTful interfaces alongside traditional OPC UA client-server communication.</li>\n</ol><section class=\"engineering-check\"><h2 id=\"apply-this-to-your-project\">Apply this to your project</h2><ul><li>Specify payload structure, units, identity, time semantics, access permissions, and protocol versions.</li><li>Test backlog growth, connection loss, duplicate delivery, and restart behavior at the consuming application.</li><li>Document how operators see failures and how the system distinguishes replayed data from current process state.</li></ul><p><a href=\"https://wiki.aspotomasyon.com/guides\">Follow an ASP project guide</a> to connect the fundamentals with implementation and acceptance.</p></section><figure class=\"article-figure\"><img src=\"https://wiki.aspotomasyon.com/assets/diagrams/modern-connectivity-review.svg\" width=\"1100\" height=\"460\" loading=\"lazy\" decoding=\"async\" alt=\"Engineering review sequence: Contract → Connect → Interrupt → Reconcile. Keep the recorded evidence with the accepted configuration.\"><figcaption>Engineering review sequence: Contract → Connect → Interrupt → Reconcile. Keep the recorded evidence with the accepted configuration. <a href=\"https://wiki.aspotomasyon.com/assets/diagrams/modern-connectivity-review.svg\" target=\"_blank\" rel=\"noopener\">View full size</a></figcaption></figure><h2 id=\"primary-references-and-further-reading\">Primary references and further reading</h2><p>Use the original specifications and product documentation for implementation details. The examples in this guide are illustrative engineering scenarios, not published project results.</p><ul><li><a href=\"https://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-v5.0.html\" rel=\"noopener noreferrer\" target=\"_blank\">OASIS — MQTT 5.0 specification</a></li><li><a href=\"https://www.modbus.org/modbus-specifications\" rel=\"noopener noreferrer\" target=\"_blank\">Modbus Organization — Protocol specifications</a></li><li><a href=\"https://sparkplug.eclipse.org/specification/version/3.0/\" rel=\"noopener noreferrer\" target=\"_blank\">Eclipse Foundation — Sparkplug 3.0 specification</a></li></ul><!-- asp-editorial-202609 -->","markdown":"# REST APIs for Industrial Automation — Bridging OT and IT\n\n> REST APIs (Representational State Transfer Application Programming Interfaces) have become the standard method for integrating industrial automation systems…\n\n- Canonical URL: https://wiki.aspotomasyon.com/article/rest-apis-for-industrial-automation\n- Publisher: ASP OTOMASYON A.Ş. (ASP OTOMASYON Wiki)\n- Category: Modern Connectivity\n- Published: 2026-05-13 · Updated: 2026-09-13\n- Reading time: 8 min · Language: English\n\n**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.\n\n![A generic industrial messaging path. A network or broker acknowledgment is not necessarily confirmation that a downstream business action succeeded.](https://wiki.aspotomasyon.com/assets/diagrams/modern-connectivity-context.svg)\n\n*A generic industrial messaging path. A network or broker acknowledgment is not necessarily confirmation that a downstream business action succeeded.*\n\n---\n\n## RESTful Design Patterns for Industrial Data\n\nA 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).\n\n### Resource Naming Conventions\n\nIndustrial resources should be named using nouns (not verbs) and organised hierarchically to reflect the plant structure. Common resource patterns include:\n\n- `/api/v1/equipment` — List all equipment assets. Supports query parameters for filtering by area, type, status.\n- `/api/v1/equipment/{equipmentId}` — Details for a specific equipment item.\n- `/api/v1/tags/{tagId}` — Read a specific process tag's current value and metadata (engineering units, description, data type).\n- `/api/v1/tags/{tagId}/history?from=2025-01-01T00:00:00Z&to=2025-01-02T00:00:00Z` — Retrieve historical values.\n- `/api/v1/batches/{batchId}` — Fetch batch record details, phase execution timeline, and process values.\n- `/api/v1/alarms` — List active alarms. Supports filtering by priority, area, and time range.\n- `/api/v1/orders/{orderId}/start` — POST a command to begin executing a production order.\n\n### HTTP Methods and Their Industrial Semantics\n\n- **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.\n- **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.\n- **PUT** — Full replacement of a resource. Idempotent. Example: `PUT /api/v1/recipes/CHOCOLATE-001` replaces the entire recipe definition.\n- **PATCH** — Partial update of a resource. Example: `PATCH /api/v1/tags/TT-101` to update the tag's alarm limits.\n- **DELETE** — Remove a resource. Example: `DELETE /api/v1/alarms/12345` to acknowledge and clear an alarm.\n\n### URL Structure Best Practices for Industrial APIs\n\n- **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.\n- **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.\n- **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).\n- **Sorting** — Use `?sort=name:asc` or `?sort=timestamp:desc` for ordered results.\n\n## Authentication Methods for Industrial REST APIs\n\n### API Keys\n\nAPI 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.\n\n### OAuth 2.0\n\n**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.\n\n### Mutual TLS (mTLS)\n\nIn 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.\n\n## Rate Limiting and Data Throttling\n\nIndustrial 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:\n\n- **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.\n- **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.\n- **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.\n- **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.\n\n## Data Format Standards\n\n- **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:\n\n```\n{\n  \"tagName\": \"FT-101\",\n  \"value\": 150.25,\n  \"unit\": \"m³/h\",\n  \"quality\": \"good\",\n  \"timestamp\": \"2025-03-15T14:30:00.000Z\"\n}\n```\n\n- **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.\n- **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).\n\n## Real Integration Example — SCADA to ERP\n\nA 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:\n\n1. The SCADA system collects actual production counts from PLCs on each packaging line (units produced, rejects, machine status) every minute.\n2. 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:\n\n```\n{\n  \"lineId\": \"LINE-01\",\n  \"periodStart\": \"2025-03-15T06:00:00Z\",\n  \"periodEnd\": \"2025-03-15T07:00:00Z\",\n  \"totalGoodCount\": 5420,\n  \"totalRejectCount\": 38,\n  \"lineSpeed\": 95.2,\n  \"status\": \"running\"\n}\n```\n\n1. 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.\n2. 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.\n\n## Error Handling — Consistent Error Responses\n\nA well-designed industrial API returns consistent, structured error responses:\n\n```\n{\n  \"error\": {\n    \"code\": \"TAG_NOT_FOUND\",\n    \"message\": \"The tag 'TT-999' does not exist in the plant model.\",\n    \"status\": 404,\n    \"timestamp\": \"2025-03-15T14:30:00.000Z\",\n    \"requestId\": \"req-abc-123\"\n  }\n}\n```\n\nStandard HTTP status codes for industrial APIs:\n\n- **200 OK** — Successful GET, PUT, PATCH\n- **201 Created** — Successful POST (resource created)\n- **400 Bad Request** — Invalid parameters, malformed JSON\n- **401 Unauthorized** — Missing or invalid authentication\n- **403 Forbidden** — Authenticated but insufficient permissions\n- **404 Not Found** — Resource does not exist\n- **409 Conflict** — State conflict (e.g., starting a batch that is already running)\n- **422 Unprocessable Entity** — Semantic error (e.g., setpoint out of range)\n- **429 Too Many Requests** — Rate limit exceeded\n- **500 Internal Server Error** — Unexpected server failure\n- **503 Service Unavailable** — Server temporarily unable to handle request (e.g., historian offline)\n\n> ASP OTOMASYON A.Ş. and its subsidiaries OPCTurkey and ASP Dijital provide end-to-end industrial engineering solutions for process automation, data operations and AI.\n\n---\n\n## References & Further Reading\n\n1. [OAuth 2.0 Authorization Framework — RFC 6749](https://oauth.net/2/) — Official IETF standard for delegated authorisation, defining the protocol flow, token types, and grant types used in REST API security for industrial applications.\n2. [OpenAPI Specification 3.1 — Standard for REST API Description](https://spec.openapis.org/oas/v3.1.0) — Official OpenAPI specification for describing, producing, consuming, and visualising RESTful web services, widely adopted for industrial API documentation.\n3. [HTTP/1.1 — Semantics and Content (RFC 7231)](https://www.ietf.org/rfc/rfc7231.txt) — Official IETF specification for HTTP methods, status codes, and request/response semantics fundamental to proper REST API design.\n4. [ISA-95 / IEC 62264 — Enterprise-Control System Integration](https://www.isa.org/standards-and-publications/isa-standards/isa-95-standard) — International standard defining the information models and data flows that REST APIs must implement for bridging OT systems with enterprise IT applications.\n5. [OPC Foundation — REST API Integration Patterns](https://reference.opcfoundation.org/specs/OPC-10000-1) — Official OPC UA documentation on exposing industrial data through RESTful interfaces alongside traditional OPC UA client-server communication.\n\n## Apply this to your project\n\n- Specify payload structure, units, identity, time semantics, access permissions, and protocol versions.\n- Test backlog growth, connection loss, duplicate delivery, and restart behavior at the consuming application.\n- Document how operators see failures and how the system distinguishes replayed data from current process state.\n\n[Follow an ASP project guide](https://wiki.aspotomasyon.com/guides) to connect the fundamentals with implementation and acceptance.\n\n![Engineering review sequence: Contract → Connect → Interrupt → Reconcile. Keep the recorded evidence with the accepted configuration.](https://wiki.aspotomasyon.com/assets/diagrams/modern-connectivity-review.svg)\n\n*Engineering review sequence: Contract → Connect → Interrupt → Reconcile. Keep the recorded evidence with the accepted configuration.*\n\n## Primary references and further reading\n\nUse the original specifications and product documentation for implementation details. The examples in this guide are illustrative engineering scenarios, not published project results.\n\n- [OASIS — MQTT 5.0 specification](https://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-v5.0.html)\n- [Modbus Organization — Protocol specifications](https://www.modbus.org/modbus-specifications)\n- [Eclipse Foundation — Sparkplug 3.0 specification](https://sparkplug.eclipse.org/specification/version/3.0/)\n\n---\n\nCite the canonical article: https://wiki.aspotomasyon.com/article/rest-apis-for-industrial-automation (REST APIs for Industrial Automation — Bridging OT and IT, ASP OTOMASYON, updated 2026-09-13).\n","headings":[{"id":"restful-design-patterns-for-industrial-data","title":"RESTful Design Patterns for Industrial Data"},{"id":"authentication-methods-for-industrial-rest-apis","title":"Authentication Methods for Industrial REST APIs"},{"id":"rate-limiting-and-data-throttling","title":"Rate Limiting and Data Throttling"},{"id":"data-format-standards","title":"Data Format Standards"},{"id":"real-integration-example-scada-to-erp","title":"Real Integration Example — SCADA to ERP"},{"id":"error-handling-consistent-error-responses","title":"Error Handling — Consistent Error Responses"},{"id":"references-further-reading","title":"References & Further Reading"},{"id":"apply-this-to-your-project","title":"Apply this to your project"},{"id":"primary-references-and-further-reading","title":"Primary references and further reading"}],"faq":[],"references":[{"name":"OAuth 2.0 Authorization Framework — RFC 6749","url":"https://oauth.net/2/"},{"name":"OpenAPI Specification 3.1 — Standard for REST API Description","url":"https://spec.openapis.org/oas/v3.1.0"},{"name":"HTTP/1.1 — Semantics and Content (RFC 7231)","url":"https://www.ietf.org/rfc/rfc7231.txt"},{"name":"ISA-95 / IEC 62264 — Enterprise-Control System Integration","url":"https://www.isa.org/standards-and-publications/isa-standards/isa-95-standard"},{"name":"OPC Foundation — REST API Integration Patterns","url":"https://reference.opcfoundation.org/specs/OPC-10000-1"},{"name":"OASIS — MQTT 5.0 specification","url":"https://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-v5.0.html"},{"name":"Modbus Organization — Protocol specifications","url":"https://www.modbus.org/modbus-specifications"},{"name":"Eclipse Foundation — Sparkplug 3.0 specification","url":"https://sparkplug.eclipse.org/specification/version/3.0/"}],"related":[{"slug":"cloud-scada-remote-monitoring","title":"Cloud SCADA and Remote Monitoring Architectures","summary":"Cloud SCADA and remote monitoring extend the plant control and visibility layer beyond the control room.","category":{"slug":"digital-transformation","name":"Digital Transformation"},"url":"https://wiki.aspotomasyon.com/article/cloud-scada-remote-monitoring","markdown_url":"https://wiki.aspotomasyon.com/article/cloud-scada-remote-monitoring.md","api_url":"https://wiki.aspotomasyon.com/api/v1/articles/cloud-scada-remote-monitoring","published":"2026-08-06T12:26:37+00:00","modified":"2026-09-13T11:07:23+00:00","reading_minutes":5,"word_count":984,"image":"https://wiki.aspotomasyon.com/assets/social/cloud-scada-remote-monitoring-dd8794c627d4.png"},{"slug":"industrial-ethernet-redundancy-rstp-mrp-prp-hsr","title":"Industrial Ethernet Redundancy: RSTP, MRP, PRP and HSR Compared","summary":"A redundant industrial network needs a protocol matched to its topology and device support, plus a failover test that records what the control system actually…","category":{"slug":"technical-guides","name":"Technical Guides"},"url":"https://wiki.aspotomasyon.com/article/industrial-ethernet-redundancy-rstp-mrp-prp-hsr","markdown_url":"https://wiki.aspotomasyon.com/article/industrial-ethernet-redundancy-rstp-mrp-prp-hsr.md","api_url":"https://wiki.aspotomasyon.com/api/v1/articles/industrial-ethernet-redundancy-rstp-mrp-prp-hsr","published":"2026-10-11T11:46:21+00:00","modified":"2026-10-11T11:46:21+00:00","reading_minutes":9,"word_count":1911,"image":"https://wiki.aspotomasyon.com/assets/social/industrial-ethernet-redundancy-rstp-mrp-prp-hsr-8977742b8d7a.png"},{"slug":"opc-ua-mqtt-bridge-patterns","title":"OPC UA to MQTT Bridge Patterns","summary":"Industrial automation environments increasingly demand a two-tier data strategy: OPC UA for real-time, deterministic plant-floor communication and MQTT for…","category":{"slug":"opc-solutions","name":"OPC Solutions"},"url":"https://wiki.aspotomasyon.com/article/opc-ua-mqtt-bridge-patterns","markdown_url":"https://wiki.aspotomasyon.com/article/opc-ua-mqtt-bridge-patterns.md","api_url":"https://wiki.aspotomasyon.com/api/v1/articles/opc-ua-mqtt-bridge-patterns","published":"2026-05-13T12:01:15+00:00","modified":"2026-09-13T11:07:23+00:00","reading_minutes":8,"word_count":1649,"image":"https://wiki.aspotomasyon.com/assets/social/opc-ua-mqtt-bridge-patterns-b71382141389.png"},{"slug":"quality-4-0-digital-quality","title":"Quality 4.0: Digital Quality Management Systems","summary":"Quality 4.0 is the application of digital technologies to quality management: connecting quality data across the value stream, analyzing it continuously, and…","category":{"slug":"digital-transformation","name":"Digital Transformation"},"url":"https://wiki.aspotomasyon.com/article/quality-4-0-digital-quality","markdown_url":"https://wiki.aspotomasyon.com/article/quality-4-0-digital-quality.md","api_url":"https://wiki.aspotomasyon.com/api/v1/articles/quality-4-0-digital-quality","published":"2026-08-11T13:05:19+00:00","modified":"2026-09-13T11:07:23+00:00","reading_minutes":5,"word_count":881,"image":"https://wiki.aspotomasyon.com/assets/social/quality-4-0-digital-quality-6ec80a0fcc0b.png"}],"citation":"ASP OTOMASYON. REST APIs for Industrial Automation — Bridging OT and IT. Updated 2026-09-13. https://wiki.aspotomasyon.com/article/rest-apis-for-industrial-automation"}}