What Is a REST API — Explained Without Jargon
«We need to integrate with their API.» You hear this from your developer, from eMAG, from your accountant. What does it actually mean, how much does it cost, and why can't you just copy the data manually? The answer is simpler than it sounds.
The waiter analogy
Imagine you walk into a restaurant. You sit at a table, the kitchen is in the back. You don't go into the kitchen to get your food — you call the waiter, tell them what you want, they take the order to the kitchen and bring back your plate. The waiter is the API. You (the client) don't have direct access to the kitchen (the server and database). The waiter takes your order in a standardized format («one grilled pork loin, no potatoes»), carries it where it needs to go, and brings you the result.
In software: your app wants data from another system. It doesn't connect directly to that system's database — that would be insecure and impossible to scale. It sends a request to a specific URL and gets back a response in a format it can read. That's it.
What REST means
REST stands for Representational State Transfer. It's a set of conventions about how those requests and responses should look. It's not a technology — it's an architectural style defined in 2000 by Roy Fielding in his doctoral dissertation. Nearly every public API built in the last 15 years uses REST.
The key word in REST is resource. A resource is any entity you work with: a product, a customer, an order, an invoice. Each resource has a unique identifier — a URL. For example: https://api.yourstore.com/products/4821 identifies product ID 4821.
The four basic operations
REST uses verbs from the HTTP protocol to say what you want to do with a resource. Four of them cover 95% of cases:
| HTTP verb | What it does | Business equivalent |
|---|---|---|
GET | Reads data | «Show me product 4821» |
POST | Creates something new | «Add a new order» |
PUT / PATCH | Modifies something existing | «Change the price of product 4821» |
DELETE | Deletes | «Cancel order 7732» |
Those same four verbs, combined with different URLs, form everything your app does with external data. The rest is detail.
What a request and response look like
Your app sends an HTTP request. Here's a concrete example — fetching product data:
The request:
GET /products/4821 HTTP/1.1
Host: api.yourstore.com
Authorization: Bearer secret_key The response:
HTTP/1.1 200 OK
Content-Type: application/json
{
"id": 4821,
"name": "Organic Face Cream",
"price": 129.90,
"currency": "RON",
"stock": 34
} The format in the response is called JSON (JavaScript Object Notation). It's structured text that any programming language can read. Nothing mystical — keys and values separated by commas, enclosed in curly braces.
Authentication — how the API knows who you are
An API without authentication would let anyone read or modify your data. That's why nearly every API requires proof that you have the right to access the resource. Three common methods:
- API key — a string of characters you send in the request header. Simple, used by Stripe, Google Maps, most SaaS services. You generate the key from your account dashboard.
- OAuth 2.0 — the protocol used when a user grants your app permission to access their account in another service («Sign in with Google»). Used by government e-invoicing APIs, Facebook, GitHub.
- JWT (JSON Web Token) — a digitally-signed token the server gives you after login. You attach it to every subsequent request. Standard for apps with user accounts.
APIs you already use every day
If you have an online store or an app, you're probably already using 5-10 APIs without counting them:
- Stripe / PayPal — card payment processing. When the customer clicks «Pay», your site sends the data to the Stripe API, which returns «payment accepted» or «declined».
- Google Maps — the map on your contact page or delivery distance calculation. Takes GPS coordinates and returns an image or a distance.
- Amazon / eBay Marketplace — stock and price synchronization. Your site sends
PUT /products/123with the new price, and the marketplace updates the listing. - Government e-invoicing — submitting mandatory electronic invoices. Your app generates the invoice XML and sends it to the government API.
- Shipping carriers (UPS, DPD, DHL) — generating tracking numbers and labels directly from the order, without opening the carrier portal.
When you need an API integration in your business
- You want to automate a manual task — if your employee copies orders from one system to another 50 times a day, an API integration does that in 0 seconds with no human errors.
- You want to sync data between two systems — the stock in your ERP should reflect in your online store and on the marketplace simultaneously, not tomorrow morning.
- You're adding a feature that doesn't make sense to build from scratch — payments, maps, transactional email, SMS. You use the ones built by companies that have already perfected them.
- You need to comply with a regulation — e-invoicing mandates are compulsory via API for volumes above thresholds set by tax authorities.
HTTP status codes — what they mean for you
Every response comes with a 3-digit numeric code. The ones you need to know:
- 200 OK — the request succeeded, the data is in the body.
- 201 Created — the resource was created (after POST).
- 400 Bad Request — your request is malformed (missing field, invalid value).
- 401 Unauthorized — the token is missing or expired.
- 403 Forbidden — you have a token, but no permission for this resource.
- 404 Not Found — the resource doesn't exist (product 4821 was deleted).
- 429 Too Many Requests — you sent too many requests in a short time (rate limiting).
- 500 Internal Server Error — the problem is on their end, not yours. Try again later.
A solid integration doesn't just send the request — it treats each of these codes differently: retry on 500 and 429, re-authenticate on 401, surface a validation error on 400.
How much an API integration costs
It depends on the complexity of the API you're integrating with and how robust the error handling needs to be. Real ranges:
| Integration type | Duration | Price (EUR) |
|---|---|---|
| Simple API (read-only, one endpoint, no complex auth) | 1-3 days | €500 – €1,500 |
| Standard API (full CRUD, API key, webhooks) | 3-7 days | €1,500 – €4,000 |
| Complex API (OAuth, retry logic, bidirectional sync) | 1-3 weeks | €4,000 – €10,000 |
| Government e-invoicing (XML, OAuth, digital signatures) | 1-2 weeks | €2,500 – €7,000 |
The biggest cost factor isn't the API itself, but handling error cases: what happens when their server goes down, when the token expires, when the response format changes without warning. A well-built integration handles all of these. A quickly-built one ignores them — and you pay for it in production, in the form of lost orders or unsubmitted invoices.