Learn · Backend & APIs
APIs & REST
An API is how two programs talk. When your phone app loads your data, it’s calling an API on a server. REST is the most common style for building them — and Siemens builds REST services, so this matters.
Before we start
- What an API is and what REST means
- The HTTP methods (GET/POST/PUT/DELETE) and what they do
- Anatomy of a request and response (+ JSON)
- Status codes: 2xx / 4xx / 5xx
- Design REST endpoints for a resource
- Read a request/response and know what each part means
- Explain how a frontend talks to a backend
Why you’re learning it: every backend job is “build and consume APIs.” It’s the daily work at Ayris, the core of Spring Boot, and a guaranteed interview topic. ⏱️ ~30 min.
What is an API? — the restaurant
Picture a restaurant. You (the client) don’t walk into the kitchen — you read the menu (the API: what you’re allowed to ask for), tell the waiter (the request), the kitchen (the server) cooks, and the waiter brings back your dish (the response). The API is the menu + waiter: a clear contract for asking without needing to know how the kitchen works.
REST — resources + verbs
REST models everything as resources with URLs, and uses HTTP methods as the verbs that act on them. A resource is a noun (/users); the method is the action.
| Method | Does | Example |
|---|---|---|
| GET | Read data. “Give me user 123.” | GET /users/123 |
| POST | Create something new. | POST /users |
| PUT / PATCH | Update an existing thing. | PUT /users/123 |
| DELETE | Remove it. | DELETE /users/123 |
These four map to CRUD — Create, Read, Update, Delete — the basic things you do to any data.
Anatomy of a call
- Method + URL (POST /users)
- Headers (auth token, content type)
- Body — the data, usually JSON
- Status code (200, 404…)
- Headers
- Body — the result, usually JSON
POST /users // create a user
Content-Type: application/json
{ "name": "Darshan", "email": "d@x.com" }
→ 201 Created
{ "id": 123, "name": "Darshan" }JSON is just text in key: value form — the universal language APIs speak.
Status codes — the 3 families
| 200 OK | Success (GET/PUT worked) |
| 201 Created | Success, a new thing was made (POST) |
| 400 Bad Request | You sent something invalid |
| 401 / 403 | Not logged in / not allowed |
| 404 Not Found | That resource doesn’t exist |
| 500 Server Error | The server broke (not your fault) |
Shortcut: 2xx = it worked · 4xx = you messed up · 5xx = the server messed up.
Where you’ll use it — real life
Your phone apps are frontends calling APIs. Load a screen = a GET; submit a form = a POST.
A @RestController is you building REST endpoints — the SplitEase API in your roadmap.
EMV/payment flows are API calls between merchant, switch and bank — you already live here.
A POST that retries shouldn’t double-charge — “safe to repeat” is a key REST/payments idea.
Now YOU do the reps
- Design endpoints for a “payments” resource: create a payment, fetch one, list them, cancel one. Which method + URL for each?
- For each, what status code means success? What if the payment id doesn’t exist?
Out loud: “What is a REST API, what do GET/POST/PUT/DELETE do, and what do 2xx/4xx/5xx mean?” Then log it in your Journal.
Next: Authentication →