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.

Related Terms

API (Application Programming Interface)

An API (Application Programming Interface) is a defined contract that lets one software system request data or trigger functions in another, specifying the available operations, the structure of requests and responses, and the rules for authentication and error handling.

SOAP

SOAP is an XML-based messaging protocol for exchanging structured information between systems, in which each message is an envelope containing an optional header and a body, and the available operations are formally described by a WSDL contract.

Webhook

A webhook is an HTTP callback in which a source system automatically sends an HTTP request to a subscriber-provided URL when a defined event occurs, pushing notification to the consumer instead of requiring the consumer to poll for changes.

Go Deeper

Free Tool

ITAR Compliance Checklist for Manufacturers

A 32-point checklist covering DDTC registration, technical data controls, foreign person access, IT security, and recordkeeping for ITAR-regulated manufacturers.

CMMC-Compliant AI Deployment: What Level 2 Contractors Must Know

CMMC-compliant AI deployment explained: how Level 2 defense contractors can run AI on CUI without expanding assessment scope. Controls, enclaves, and costs.

AI Governance for Export-Controlled Data (ITAR/EAR)

ITAR compliant AI governance for export-controlled data: acceptable use policy, access controls and audit trails that keep ITAR and EAR data out of public LLMs.

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

Talk to an Expert Browse the Full Glossary

Back to Glossary

Try it here, free

NetSuite Script and REST Error Codes Reference

Open full tool

Common NetSuite error names and HTTP status codes with the usual cause and the first thing to check.

Download:

Error name or status	Where you see it	Usual cause	First thing to check
SSS_USAGE_LIMIT_EXCEEDED	SuiteScript	Script used more governance units than its type allows	Move heavy loops to Map/Reduce, use runPaged, avoid record.load inside loops
SSS_TIME_LIMIT_EXCEEDED	SuiteScript	Script ran longer than the maximum execution time	Reduce work per run or split across a queued or Map/Reduce task
SSS_MISSING_REQD_ARGUMENT	SuiteScript	An API call was made without a required argument	Read the message for the argument name and check the options object keys
SSS_INVALID_TYPE_ARG	SuiteScript	Record or search type string is not valid	Use the lowercase record type id and confirm the feature is enabled
SSS_INVALID_API_USAGE	SuiteScript	API called in a context where it is not allowed	Check the script type and mode, for example client versus server
SSS_INVALID_URL	SuiteScript	URL passed to N/https or N/http is malformed	Include the scheme and a full host, and encode query parameters
SSS_FILE_CONTENT_SIZE_EXCEEDED	SuiteScript	File content is larger than the allowed size	Split the file or reduce the payload before saving
INVALID_FLD_VALUE	SuiteScript and REST	Value is not valid for the field, such as a bad list id or date format	Check the field type and use internal ids for list fields
INVALID_KEY_OR_REF	SuiteScript and REST	Reference points to a record or key that does not exist or is inactive	Verify the internal id and that the target record is active
RCRD_DSNT_EXIST	SuiteScript and REST	The record does not exist or the role cannot see it	Confirm the id, record type and the role used by the script or token
RCRD_HAS_BEEN_CHANGED	SuiteScript	Record was edited by another user or process after you loaded it	Reload, reapply the change and save, or use submitFields for small edits
INSUFFICIENT_PERMISSION	SuiteScript and REST	The role does not have the permission level required	Check role permissions for the record type and script execute-as role
USER_ERROR	SuiteScript and UI	A validation or custom error was raised on purpose	Read the message text, which is usually written by a script or workflow
UNEXPECTED_ERROR	SuiteScript and REST	Server hit an error it could not classify	Check the Execution Log and System Notes, then retry with a simpler payload
INVALID_LOGIN_ATTEMPT	Web services	Authentication failed for the supplied credentials or token	Check account id, token values, role and that the integration is enabled
HTTP 400	REST	Request body or query is invalid	Validate the JSON shape and field names against the record metadata
HTTP 401	REST and RESTlet	Authentication missing or invalid	Check the signature, timestamp, token and account id in the Authorization header
HTTP 403	REST and RESTlet	Authenticated but not allowed	Check role permissions and the REST web services permission
HTTP 404	REST	Record or endpoint not found	Check the URL path, record type, internal id and account domain
HTTP 429	REST and SOAP	Too many concurrent requests for the account	Reduce parallel calls, add retry with backoff, review concurrency limits

Names and wording can vary by release and endpoint. Use this as a first-pass troubleshooting aid and confirm in the Execution Log, the response body and the Help Center.