REST API Design for Industrial Applications: Principles That Matter in Production

Resource Naming for Factory Data

REST URLs should be nouns, not verbs. Good: GET /api/machines/M003/oee?date=2026-03-22. Bad: GET /api/getOEEForMachine?id=M003&date=2026-03-22. Use plural nouns for collections (/machines, /batches, /alarms). Use nested resources for relationships (/lines/L01/machines). Use query parameters for filtering, sorting, and pagination — not path segments.

Versioning Strategy

Industrial APIs evolve as requirements change. Embed the version in the URL path: /api/v1/machines. When you introduce breaking changes, create /api/v2 while maintaining /api/v1 for existing clients. Never silently change response structure in an existing version — factory systems integrated against your API may have no automatic update mechanism.

Error Response Design

Industrial APIs must have consistent, informative error responses. Always return JSON error objects with: code (machine-readable error code), message (human-readable description), field (which field caused the error, for validation errors), and timestamp. Never return HTML error pages from API endpoints — frontend code cannot parse them.

Rate Limiting for Machine Data Ingestion

Factory machines may send data faster than your API can process — especially during alarm floods (20 machines all reporting faults simultaneously). Implement rate limiting per client (machine IP or API key). Use a queue (Redis or RabbitMQ) as a buffer between ingestion and processing. Return HTTP 429 with a Retry-After header when limits are hit.