What is a REST API? Concepts, methods, and examples

A REST API is a way for two systems to exchange data over HTTP using a small set of standard methods, where each piece of data is treated as a resource with its own address. REST stands for Representational State Transfer, an architectural style defined by Roy Fielding in 2000. This guide gives a plain definition, maps the HTTP verbs you will actually use, walks through one request and response, and shows where REST fits next to other API styles.

By Kanika Mathur, Head of Service Delivery

Reviewed by Resourcifi engineeringPublished Mar 8, 2026Updated Mar 8, 20267 min read

APIs

Key takeaways

The short version

REST is an architectural style, not a protocol or a product. It describes how systems should exchange data over HTTP, and APIs that follow it are called RESTful.
Everything is a resource with its own URL. You act on a resource by sending an HTTP method to its address, and the server returns a representation, usually JSON.
Five methods cover most work: GET reads, POST creates, PUT replaces, PATCH partially updates, and DELETE removes. GET, PUT, and DELETE are idempotent; POST is not.
REST is stateless. Each request carries everything the server needs, so the server keeps no session memory between calls, which makes REST easy to scale and cache.
REST suits straightforward CRUD APIs. GraphQL lets clients shape one query to avoid over-fetching, and SOAP is an older protocol built around operations rather than resources.

What a REST API is

A REST API is an application programming interface that lets two systems exchange data over HTTP by treating each item of data as a resource with its own URL. REST stands for Representational State Transfer, an architectural style Roy Fielding defined in his 2000 doctoral dissertation. A client requests a resource, and the server returns a representation of its current state, most often as JSON. APIs that follow these rules are described as RESTful.

REST is a set of constraints rather than a strict specification. Fielding describes six that together make a system RESTful, and most teams treat the first few as the ones that matter day to day.

Client-server: the client and the server are separate and evolve independently.
Stateless: each request carries all the context it needs, so the server stores no session state between calls.
Cacheable: responses say whether they can be stored, so clients and intermediaries can reuse them.
Uniform interface: resources are identified by URLs and acted on through a standard, predictable set of methods.
Layered system: proxies, gateways, and load balancers can sit between client and server without either side knowing.
Code on demand: the server may optionally send executable code to the client, the only constraint that is not required.

If you want the broader picture of how interfaces connect software, start with our explainer on what an API is, then return here for the REST specifics.

The HTTP methods a REST API uses

A REST API maps actions to standard HTTP methods, also called verbs. The five you will use most are GET to read a resource, POST to create one, PUT to replace one, PATCH to update part of one, and DELETE to remove one. The method tells the server what you intend to do, and the URL says which resource you mean. The table below summarizes each verb with a short example.

Common REST API methods and what they do
Method	What it does	Example
GET	Reads a resource; safe and idempotent	GET /users/42
POST	Creates a new resource; not idempotent	POST /users
PUT	Replaces a resource in full; idempotent	PUT /users/42
PATCH	Updates part of a resource	PATCH /users/42
DELETE	Removes a resource; idempotent	DELETE /users/42

Two properties shape how these behave. A method is safe when it only reads and changes nothing, which is true of GET. A method is idempotent when sending it many times has the same effect as sending it once, which holds for GET, PUT, and DELETE but not for POST. Designing around these rules is part of how our teams approach custom software development so APIs stay predictable as they grow.

A simple request and response

A REST call has two halves. The request names a method, a URL, and headers, plus a body when you are sending data. The response returns a status code that reports the outcome and a body that carries the resource, usually as JSON. A successful read returns status 200, a successful create returns 201, and a missing resource returns 404. Below is a request to read user 42 and the response the server sends back.

The client sends a GET request to the resource address, asking for JSON:

One GET request and its response
Part	Value
Request line	GET /users/42 HTTP/1.1
Request header	Accept: application/json
Status	200 OK
Response header	Content-Type: application/json
Response body	{ "id": 42, "name": "Ada", "role": "admin" }

To create a user instead, the client sends POST /users with a JSON body describing the new record, and the server replies 201 Created with the stored resource and its new URL. The same pattern, a method plus a URL plus an optional body, repeats across the whole API, which is what makes REST predictable to learn and to integrate.

REST vs other API styles

REST is one of several ways to design an API, and it remains the most widely used because it is simple to build, test, and cache. The main alternatives are GraphQL and SOAP. GraphQL is a query language that exposes a single endpoint and lets the client shape exactly what data comes back, which reduces over-fetching but adds caching and tooling work. SOAP is an older, stricter protocol organized around operations and XML messages, still common in enterprise and financial systems. The neutral rule is to match the style to the problem.

REST: resources at many URLs, standard HTTP methods. Best for clear CRUD APIs that benefit from HTTP caching.
GraphQL: one endpoint, client-defined queries. Useful when clients need varied, nested data and you want to avoid over-fetching.
SOAP: operation-based protocol using XML and formal contracts. Common where strict standards and legacy systems apply.

REST's staying power is not theoretical. According to the Postman 2025 State of the API Report, which surveyed more than 5,700 developers and architects, REST remains the most widely adopted API architectural style, with adoption far ahead of GraphQL, WebSockets, and SOAP. Its simplicity and native fit with HTTP caching are the main reasons teams keep choosing it as their default.

For a deeper, hands-on comparison of the two modern styles, see our guide on REST vs GraphQL. If your team is building a web product or platform that needs a clean API layer, our web development practice designs and ships REST-based interfaces as a first-class part of the architecture. For AI-powered products with more complex data flows, the AI application development team applies the same discipline to the API contracts that connect models to clients.

Frequently asked

REST API questions

What does REST stand for?

REST stands for Representational State Transfer. It is an architectural style that Roy Fielding defined in his 2000 doctoral dissertation to describe how systems should exchange data over the web. The name captures the core idea: a client asks for a resource, and the server transfers a representation of that resource current state, most often as JSON. An API that follows the REST constraints is commonly described as RESTful rather than simply REST.

What is the difference between REST and a REST API?

REST is the architectural style, a set of constraints for how systems should communicate over HTTP. A REST API is a concrete interface that applies those constraints so two systems can exchange data. In everyday use the terms blur together, and many people call any HTTP interface a REST API even when it does not follow every constraint. The precise word for an interface that does follow the REST rules is RESTful.

Which HTTP methods does a REST API use?

A REST API maps actions to standard HTTP methods. The five most common are GET to read a resource, POST to create one, PUT to replace one in full, PATCH to update part of one, and DELETE to remove one. GET is safe because it only reads. GET, PUT, and DELETE are idempotent, meaning repeating the call has the same effect as making it once, while POST is not, since it can create a new resource each time.

What does it mean that a REST API is stateless?

Stateless means the server keeps no memory of previous requests between calls. Each request must carry everything the server needs to handle it, including any authentication and parameters. The server processes that request on its own and then forgets it. This makes a REST API easier to scale, because any server in a pool can answer any request, and easier to cache, because responses do not depend on hidden session context held on the server.

What format does a REST API return?

Most REST APIs return JSON, a lightweight text format that is easy for both people and programs to read. The format is not fixed by REST itself; an API can also return XML, plain text, or other media types, and the client states its preference using the Accept header. The server then describes what it sent using the Content-Type header. JSON has become the default because it is compact, language neutral, and well supported across modern tools.

When should I use REST instead of GraphQL or SOAP?

REST is a strong default for straightforward APIs built around resources, because it is simple to build, test, and cache using normal HTTP. GraphQL fits when clients need varied or nested data from one endpoint and you want to avoid over-fetching, at the cost of more caching and tooling work. SOAP suits enterprise or legacy systems that require strict contracts and XML messaging. Match the style to the problem rather than treating one as universally better.

Kanika Mathur

Head of Service Delivery, Resourcifi

I am Kanika Mathur, Head of Service Delivery at Resourcifi. My teams design and ship REST APIs as the backbone of the products we build for clients, so I care less about dogma and more about interfaces that stay clear as a system grows. This guide is the plain-language version of how we explain REST to stakeholders since 2017.

Resourcifi on LinkedIn →

Sources

MDN Web Docs, REST glossary entry (definition of Representational State Transfer).
MDN Web Docs, HTTP request methods (GET, POST, PUT, PATCH, DELETE, safe and idempotent).
Amazon Web Services, What is a RESTful API (the six REST constraints).
Roy T. Fielding, Architectural Styles and the Design of Network-based Software Architectures, 2000 (origin of REST).
Postman, 2025 State of the API Report (REST adoption across 5,700+ developers and architects).