Understanding and Using APIs
REST, HTTP, and authentication
REST is an architectural style with constraints: client-server separation, statelessness (each request carries all needed context), cacheability, a uniform interface, and a layered system. Resources are addressed by URIs and manipulated with HTTP verbs.
Map verbs to CRUD and to safety/idempotency: GET is safe and idempotent, PUT and DELETE are idempotent but not safe, POST is neither (it usually creates and can duplicate on retry), and PATCH is a partial update that is not guaranteed idempotent. Idempotent means repeating the request leaves the server in the same state - this is why clients may safely retry PUT/DELETE but must be careful retrying POST.
Status codes are heavily tested: 200 OK, 201 Created (usually with a Location header), 202 Accepted, 204 No Content, 301/302 redirects, 400 Bad Request, 401 Unauthorized (authentication missing/invalid), 403 Forbidden (authenticated but not permitted), 404 Not Found, 405 Method Not Allowed, 409 Conflict, 415 Unsupported Media Type, 429 Too Many Requests (check Retry-After), 500/502/503/504 server-side failures.
Authentication: HTTP Basic sends base64 of user:password - that is encoding, not encryption, so TLS is mandatory. Bearer tokens and API keys go in the Authorization header. OAuth 2.0 issues short-lived access tokens via grant flows; refresh tokens obtain new ones. Send Content-Type and Accept headers to describe the payload and desired response. Pagination uses limit/offset or cursor parameters; rate limiting returns 429.
Rule of thumb: if a request is idempotent, a client can retry it blindly on timeout; if it is POST, retry only with an idempotency key or a look-before-create check.