An API is a menu of things your software can ask another system to do. REST organizes that menu around resources — users, orders, posts — accessed through URLs. `GET /users/42` fetches user 42. `POST /users` creates one. `PUT` updates; `DELETE` removes. HTTP methods map to actions; JSON usually carries the data.
Status codes tell the story. 200 means success. 201 created. 400 bad request — you sent junk. 401 not logged in. 403 not allowed. 404 not found. 500 server broke. Good APIs return clear errors in JSON too, not just a blank page.
Authentication often uses tokens. Log in once, get a JWT or session cookie, send it on every request. API keys identify apps for public APIs. Never put secrets in frontend code where users can read them — proxy through your backend.
Tools like Postman, Insomnia, or `curl` let you test endpoints without writing a full app. Save example requests, share collections with your team, mock responses while the backend is not ready yet.
Version your API (`/v1/users`) so you can change things without breaking old apps. Document endpoints — OpenAPI/Swagger generates interactive docs many teams expect. Pagination, filtering, and rate limits keep large lists from crushing your server.
GraphQL and gRPC are alternatives when REST feels clumsy — GraphQL for flexible mobile clients, gRPC for fast internal services. REST still wins on simplicity and ubiquity. Learn HTTP, JSON, and status codes first; everything else builds on that foundation.