Compliance & StandardsGlossary

What Is REST API?

Also known as: RESTful API, REST web service

Definition

A REST API is a web interface that exposes application data as addressable resources over HTTP, using standard verbs such as GET, POST, PUT, PATCH, and DELETE, stateless requests, and conventional status codes, typically exchanging JSON.

REST API Explained

REST - Representational State Transfer - was described by Roy Fielding in his 2000 dissertation as an architectural style rather than a protocol. Its constraints include client-server separation, statelessness, cacheability, a uniform interface, a layered system, and optional code on demand. Most APIs called RESTful satisfy some of these constraints and not others, particularly the hypermedia constraint. In practice the industry uses REST to mean resource-oriented HTTP APIs with JSON payloads, and that pragmatic definition is what integration work deals with.

The design centers on resources identified by URIs and manipulated with HTTP verbs. A collection such as /api/salesorders is retrieved with GET, created with POST, and an individual resource at /api/salesorders/12345 is retrieved with GET, fully replaced with PUT, partially updated with PATCH, and removed with DELETE. Status codes carry meaning: 200 for success, 201 for created, 400 for a malformed request, 401 and 403 for authentication and authorization failures, 404 for a missing resource, 409 for a conflict, and 429 for rate limiting.

Statelessness is the constraint with the most operational consequence. Each request must carry everything needed to process it, including credentials, so no server-side session ties consecutive calls together. This makes horizontal scaling and load balancing straightforward, but it means multi-step business processes must be modeled explicitly - either as a resource that represents the in-progress process, or through client-managed state. Idempotency becomes important because a client that times out and retries must not create a duplicate order; idempotency keys solve this.

REST dominates new ERP and SaaS integration because of tooling and cost. Payloads are smaller than XML equivalents, browsers and mobile clients consume JSON natively, OpenAPI specifications generate clients and documentation automatically, and every language has mature HTTP libraries. Infor OS API Gateway, Salesforce, and modern ServiceMax interfaces all expose REST endpoints, and integration platforms treat REST connectors as the default.

The trade-offs matter in enterprise contexts. REST has no built-in standard for distributed transactions, message-level security, or guaranteed delivery, all of which the WS-* stack around SOAP addressed. Where a business process must span systems atomically, REST integrations implement compensating transactions or rely on a message broker. Where message-level signing or encryption is required for a regulated exchange, REST relies on transport security plus application-level signing rather than a standardized envelope.

Why It Matters

  • REST is the default for modern ERP and SaaS integration, so most connectors, tooling, and developer skills assume it.
  • Statelessness simplifies scaling but forces explicit design for multi-step business processes and retry safety.
  • Proper use of status codes and idempotency keys is what prevents duplicate orders and shipments during network failures.
  • REST lacks native distributed transaction and message-level security standards, which must be designed for in regulated integrations.

In Practice

Retry logic causes duplicate transactions more often than any other integration defect. A POST to create a sales order succeeds on the server but the response is lost to a timeout; the client retries and creates a second order. Send a client-generated idempotency key on every create request and have the receiving service return the original resource when it sees a repeated key. Without it, the safest fallback is a natural-key duplicate check on the customer PO number before insert.

Frequently Asked Questions

What makes an API RESTful?

Strictly, an API is RESTful when it satisfies the REST architectural constraints: client-server separation, statelessness, cacheability, a uniform interface including resource identification and self-descriptive messages, and a layered system. In common usage the term describes any resource-oriented HTTP API using standard verbs, conventional status codes, and JSON payloads, whether or not it implements hypermedia controls.

When should PUT be used instead of PATCH?

Use PUT when the client sends a complete representation that replaces the existing resource, which makes the operation idempotent - sending it repeatedly yields the same state. Use PATCH when sending only the fields that change. PATCH is smaller and safer against concurrent edits to unrelated fields, but implementations vary, so the API documentation should state exactly how partial updates are interpreted.

Working with REST API in a live environment? Our engineers do this every day - and our AI agents automate most of it.