REST API (representational state transfer API)

A REST API is an HTTP interface built around resources. Each thing the API manages, such as a student or an order, has a URL, and clients act on it with standard HTTP methods: GET to read, POST to create, PUT to replace and DELETE to remove. The server answers with a status code and usually a JSON body. REST stands for representational state transfer.

How it works

Resources are nouns in the path and the HTTP method carries the verb, so URLs never need names like /getStudent. Collections are plural, and one item sits under its ID. Each request is stateless: it carries everything the server needs, such as an auth token, so any server behind a load balancer can answer it. A version in the path, as in /api/v1/, lets the API change without breaking existing clients.

The One2N SRE bootcamp starts with a student CRUD API. POST /api/v1/students creates a student and returns 201 Created. GET /api/v1/students lists students with 200 OK. GET /api/v1/students/42 returns student 42, PUT /api/v1/students/42 updates it with 200 OK, and DELETE /api/v1/students/42 returns 204 No Content. After that, GET /api/v1/students/42 returns 404 Not Found.

Why it matters in production

Clients, gateways and dashboards all read the method and the status code, so getting them right pays off in operations. GET, PUT and DELETE are defined as idempotent, so a client can safely retry them after a timeout, while a retried POST can create a duplicate. Error rates in RED metrics are usually counted from 5xx responses, so an API that returns 200 with an error in the body hides its failures from monitoring.