A REST API is a widely used style for letting software exchange data over HTTP using simple, predictable rules. Instead of inventing a custom protocol, REST reuses the plumbing of the web: URLs name the data you want, and standard HTTP methods say what to do with it. Send a request, get back structured data, usually JSON. Most public and internal web APIs you will touch in 2026 follow this pattern because it is easy to learn, easy to debug, and supported everywhere.
What REST actually means
REST stands for Representational State Transfer. In plain terms it is a set of conventions, not a library you install. An API is RESTful when it organizes everything around resources, addresses them with URLs, and manipulates them with the standard HTTP methods.
A resource is any thing your system has: a user, an order, a photo. REST treats the URL as the noun and the HTTP method as the verb acting on it.
The core conventions
| HTTP method |
Action |
Example |
| GET |
Read |
Fetch the list of users |
| POST |
Create |
Add a new user |
| PUT / PATCH |
Update |
Change a user email |
| DELETE |
Remove |
Delete a user |
A request to GET /users/42 reads user 42. A request to DELETE /users/42 removes that same user. The URL stayed the same; the verb changed the intent. This predictability is the whole appeal.
// Read a public resource over a REST API, no key needed
curl https://api.github.com/repos/rust-lang/rust
Why statelessness matters
REST is stateless: the server keeps no memory of your previous request. Every request must carry everything needed to handle it, including any authentication token. This sounds like extra work, but it is what lets REST APIs scale, because any server in a cluster can handle any request without coordinating.
Status codes report the outcome:
200 succeeded201 created something400 your request was malformed401 you are not authenticated404 the resource does not exist500 the server failed
Always check the status before trusting the body. For more on the data format these responses use, see what JSON is in 2026.
REST vs GraphQL
| Style |
Strength |
Trade-off |
| REST |
Simple, cacheable, ubiquitous |
Can over-fetch or need many calls |
| GraphQL |
Client picks exact fields |
More setup, harder caching |
REST is the right default for most projects. You will meet GraphQL on large platforms where clients need flexible, precise queries. Choosing REST is rarely a mistake for a beginner or a small team.
How to design a clean REST API
- Use nouns in URLs, not verbs.
/orders, not /getOrders. The method already supplies the verb.
- Be consistent with plurals. Pick
/users and stick with it everywhere.
- Return the right status codes. Do not return
200 with an error message buried inside.
- Version your API. A
/v1/ prefix lets you change things later without breaking callers.
- Document it. Ship an OpenAPI spec so consumers get interactive docs.
Common mistakes
- Putting actions in URLs.
/users/42/delete defeats the design; use DELETE /users/42.
- Ignoring status codes. Returning everything as
200 forces clients to parse error text.
- Leaking secrets in URLs. Query strings end up in logs; send tokens in headers.
- No pagination. Returning every record at once will eventually time out. Use limits and cursors.
What to skip
- Chasing perfect REST purity. A clear, well-documented API that bends a rule beats a dogmatically correct one nobody can read.
- Inventing your own data format. JSON over HTTP is understood everywhere; reach for something else only with a concrete reason.
- Hand-rolling authentication. Use API keys, OAuth, or tokens as standard, not a homegrown scheme.
FAQ
Is REST the same as HTTP?
No. HTTP is the transport protocol. REST is a style for using HTTP in a consistent, resource-oriented way. You can use HTTP without being RESTful.
What format does a REST API return?
Usually JSON, a plain text key-value format every language can parse. Some APIs also offer XML, but JSON is the modern default.
What makes an API RESTful?
Organizing around resources, using standard HTTP methods correctly, staying stateless, and returning meaningful status codes. The more of these it follows, the more RESTful it is.
When should I choose GraphQL instead?
When clients need to request exactly the fields they want and avoid many round trips, typically on larger apps with varied frontends. For most projects REST is simpler and enough.
Where to go next
See what an API key is in 2026, what a webhook is in 2026, and SOAP vs REST in 2026.