What Is a REST API?
A REST API (Representational State Transfer Application Programming Interface) is a standardised way for applications to communicate with each other over HTTP. It uses four core methods: GET to retrieve data, POST to create it, PUT to update it, and DELETE to remove it. The server returns responses in JSON format along with a status code that tells the client whether the request succeeded or failed.
A REST API lets applications communicate over HTTP using standard methods like GET and POST, exchanging data as JSON.
How a REST API Works
When you open a weather app on your phone and it shows today’s forecast, the app is almost certainly talking to a REST API in the background. The app sends an HTTP request to a URL such as https://api.weather.com/v1/forecast?city=Amsterdam. The server receives the request, looks up the data, and sends back a JSON response with temperature, wind speed, and precipitation. The whole exchange takes a fraction of a second.
Every REST API is built around resources, things like users, products, or orders, each identified by a URL called an endpoint. The action you want to perform is expressed through the HTTP method:
- GET: retrieve a resource or a list of resources
- POST: create a new resource
- PUT or PATCH: update an existing resource
- DELETE: remove a resource
A webshop, for example, might expose GET /products to list all items, GET /products/42 to fetch a single product, and POST /orders to place a new order.
Requests and Responses
An HTTP request has three main parts: the method and URL, optional headers that carry metadata (such as an authentication token or the content type), and an optional body for POST and PUT requests. Here is what a request to create a new order might look like:
POST /orders
Authorization: Bearer eyJhbGc...
Content-Type: application/json
{
"product_id": 42,
"quantity": 3,
"customer_id": 101
}
The server validates the request and returns a response. A successful creation returns status code 201 Created along with the new order object in JSON. If the product does not exist, the server returns 404 Not Found. If something breaks in the server logic, you get 500 Internal Server Error.
Because both request and response are plain text over HTTP, you can test any REST API directly in a browser or with a tool like Postman without writing a single line of code.
REST vs. SOAP vs. GraphQL
REST replaced SOAP as the dominant API style around 2010 for good reasons. SOAP requires XML everywhere, which is verbose and hard to read, and it demands a formal contract document before you can even make a request. REST has no mandatory format and no contract; a URL and a method are often enough to understand what an endpoint does.
GraphQL, created by Meta in 2015, is a newer alternative that lets clients request exactly the fields they need. Instead of calling GET /users/5 and receiving a fixed user object, a GraphQL client sends a query like { user(id: 5) { name, email } } and receives only those two fields. This is powerful for complex frontend applications but overkill for most business integrations. If you are connecting two systems or building a straightforward API, REST is almost always the right choice.
For a deeper look at what APIs are in general, see what is an API.
Why Almost Every Modern Application Uses REST APIs
REST APIs are the connective tissue of the modern internet. When you log into a website using your Google account, OAuth 2.0 is running on top of REST APIs. When a payment provider confirms a transaction, it sends a REST callback. When an e-commerce platform checks stock levels in a warehouse management system, it calls a REST endpoint.
For businesses building or integrating software, understanding REST APIs matters because it tells you what is possible without custom development. If a tool you use exposes a REST API, it can almost certainly talk to your CRM, your marketing platform, or your automation tool. Platforms like n8n and Power Automate are built to call REST APIs without writing code.
Reading API Documentation
Every public REST API ships with documentation that lists its endpoints, the required parameters, authentication method, and example responses. Good documentation includes a “Try it” feature that lets you send live requests directly in the browser.
When you evaluate whether a tool can integrate with your existing systems, the first question to ask is: does it have a REST API? If yes, look for the authentication method (API key, OAuth 2.0, or basic auth) and the rate limits (how many requests you can make per minute or per day). Those two factors determine how practical the integration will be in production.
Our tip: Before building any integration, open the API documentation and make one real GET request with a tool like Postman or even your browser. Seeing an actual response immediately tells you whether the data structure matches what your system expects, saving hours of speculative planning.
Frequently asked questions
What is the difference between REST and SOAP?
SOAP (Simple Object Access Protocol) is an older standard that uses XML for all messages and requires a strict contract defined in a WSDL file. REST is not a protocol but an architectural style, and it is far more flexible: it accepts JSON, XML, or plain text, requires no formal contract, and works naturally over HTTP. Most modern public APIs use REST because it is simpler to build, easier to test in a browser, and produces smaller payloads than SOAP.
What do HTTP status codes 200, 404, and 500 mean?
Status codes tell the client what happened on the server. 200 OK means the request succeeded and the response body contains the requested data. 404 Not Found means the resource you requested does not exist at that URL, often because of a typo in the path or a deleted record. 500 Internal Server Error signals that something went wrong on the server itself, not in your request. Other common codes include 201 Created (a new resource was made), 400 Bad Request (your request was malformed), and 401 Unauthorized (you need to authenticate first).
What is the difference between REST and GraphQL?
GraphQL is a query language developed by Meta that lets the client specify exactly which fields it needs in a single request. With REST, the server decides what data each endpoint returns, which can result in over-fetching (receiving fields you do not need) or under-fetching (needing multiple requests to gather all the data). GraphQL solves those problems but adds complexity: you need a schema, a special query syntax, and tooling that most teams are less familiar with. REST remains the dominant choice for public APIs and straightforward integrations, while GraphQL excels in complex frontends that consume many related data types.