HTTP, APIs, Cookies and CORS

Introduction

Apps talk to servers through APIs (application programming interfaces) built on HTTP. This lesson covers the conventions developers use, and two browser features that cause endless confusion: cookies and CORS.

REST-style APIs

A REST API treats things as resources with addresses, and uses HTTP methods as the verbs.

Data usually travels as JSON. A request to create a book:

POST /books HTTP/1.1
Host: api.example.com
Content-Type: application/json
Authorization: Bearer <token>

{"title": "Learn Networking", "year": 2026}

A response:

HTTP/1.1 201 Created
Content-Type: application/json
Location: /books/43

{"id": 43, "title": "Learn Networking", "year": 2026}

Useful ideas:

• Safe methods (GET) do not change anything. Idempotent methods (GET, PUT, DELETE) give the same result if repeated. POST is not idempotent, so repeating it may create duplicates.
• Status codes tell the result: 200 OK, 201 Created, 204 No Content, 400 Bad Request, 401 Unauthorized (not signed in), 403 Forbidden (signed in but not allowed), 404 Not Found, 429 Too Many Requests, 500 Internal Server Error, 503 Service Unavailable.
• Headers carry information about the request and response, such as Content-Type, Authorization and Cache-Control.
• Good APIs are versioned, return clear error messages and use pagination for long lists.

Cookies and sessions

HTTP is stateless: each request stands alone. A cookie is a small piece of data the server asks the browser to store and send back with later requests to the same site. This is how a site remembers that you are signed in:

1. You log in. The server creates a session and replies with Set-Cookie: session=abc123.
2. Your browser sends Cookie: session=abc123 with every following request.
3. The server looks up the session and knows who you are.

Important cookie settings:

• HttpOnly: scripts cannot read the cookie, which limits theft through cross-site scripting.
• Secure: only sent over HTTPS.
• SameSite: limits sending on cross-site requests, which helps against cross-site request forgery.
• Max-Age or Expires: how long it lasts.

Cookies are also used for tracking, which is why privacy laws require consent for some of them.

The same-origin policy and CORS

Browsers protect you with the same-origin policy: a script from one origin (scheme, host and port) cannot freely read responses from another. Otherwise, any web page could read your emails from another tab where you are signed in.

Sometimes legitimate sites need to share, for example a front end at app.example.com calling an API at api.example.com. CORS (Cross-Origin Resource Sharing) lets the server opt in, using response headers:

Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Methods: GET, POST
Access-Control-Allow-Headers: Content-Type, Authorization

For some requests, the browser first sends a preflight OPTIONS request to ask permission. If the server's headers do not allow the origin, the browser blocks the script from reading the response.

Key points:

• CORS is enforced by browsers, not by servers or tools such as curl. It protects users, not your API.
• Never answer Access-Control-Allow-Origin: * on endpoints that use cookies or private data.
• A CORS error means the server needs the right headers. Changing the front end cannot fix it.

Try it yourself

Design a small API for a to-do app. List the endpoints with their methods, one request and response in JSON, and the status codes for success and for a missing item.

Summary

• REST APIs use HTTP methods on resource addresses, with JSON bodies and meaningful status codes.
• Cookies let a stateless protocol keep sessions, and HttpOnly, Secure and SameSite protect them.
• The same-origin policy protects users, and CORS lets servers selectively allow cross-origin access.