REST

Rest architectural style

REST (Representational State Transfer) is an architectural style for designing distributed systems, most commonly used for web services. In REST, functionality and data are modeled as **resources** that are addressed by URLs and manipulated using standard HTTP methods such as GET, POST, PUT, PATCH, and DELETE.

RESTful services are typically:

– **Stateless**: Each request contains all the information the server needs to process it; the server does not store session state between requests.
– **Resource-oriented**: The primary abstraction is a resource (such as an order, batch, work order, or recipe), not a function call.
– **Uniform in interface**: A consistent set of operations and representations is used across resources.
– **Representational**: Resources can be represented in different formats (commonly JSON or XML) depending on client and server agreements.

REST is a style, not a strict protocol or standard. Different implementations may vary in how strictly they follow REST principles, and the term “REST API” is often used informally to describe any HTTP-based JSON API, even if it is not fully RESTful.

Use in manufacturing and enterprise systems

In industrial and regulated manufacturing environments, REST is commonly used to implement web service APIs between systems such as:

– **MES and ERP**: Exposing production orders, material movements, inventory, or quality results as REST resources that can be created, queried, or updated.
– **OT–IT gateways**: Wrapping shop-floor data (e.g., equipment status, process parameters) from controllers or historians in REST endpoints consumed by MES, LIMS, or analytics tools.
– **Quality and compliance systems**: Providing REST endpoints for recording test results, retrieving specifications, or exchanging electronic records and metadata.

Because REST operates over HTTP/HTTPS and uses text-based payloads, it is often easier to integrate with modern enterprise platforms, iPaaS tools, and cloud services than older, proprietary protocols.

Boundaries and exclusions

REST in this context:

– **Includes**: HTTP-based APIs that expose resources and use standard verbs (GET, POST, PUT, PATCH, DELETE), usually with JSON or XML payloads.
– **Excludes**: Network timing or sleep commands (sometimes called “rest” in programming), physical equipment rest periods, and non-HTTP protocols such as OPC UA, MQTT, or classic message-queue interfaces, even though they may provide similar integration capabilities.

REST is not itself a security mechanism; authentication, authorization, encryption, and audit trails are provided by additional layers and patterns (such as OAuth, API keys, TLS, or signed payloads).

Common confusion and misuse

REST is commonly confused with or loosely used for:

– **Any HTTP API**: Many HTTP APIs are described as RESTful even if they behave more like RPC (Remote Procedure Call) over HTTP, exposing actions like `/startBatch` instead of resource-based URLs like `/batches/{id}`.
– **SOAP or XML web services**: SOAP uses XML envelopes and a different message structure, while REST emphasizes resources and is not tied to XML.
– **A standard or product**: REST is an architectural style and set of principles, not a formal standard, product, or protocol with a certification process.

When documenting MES–ERP or OT–IT integrations, it is more precise to say **”RESTful HTTP API”** or **”REST-based web service”** when the interface follows resource-oriented patterns, and simply **”HTTP API”** when the style is mixed or not strictly RESTful.