Loading published curriculum…

07 · HTTP and SQL foundations / LESSON 27 OF 102

HTTP, REST, and JSON

An API is a contract between independent programs.

Before this lesson: Repositories, profiles, and build troubleshooting

Understand the topic

A request has a method, path, headers, and optional body. A response adds a status code. GET reads, POST creates, PUT usually replaces, PATCH partially updates, and DELETE removes. Repeating an idempotent request has the same intended effect.

Use resource paths and deliberate statuses: 200, 201, 204, 400, 401, 403, 404, and 409. Authentication proves identity; authorization decides access. JSON names and types are part of your public contract.

EXAMPLE · HTTP

HTTP contract · illustration, not Java

POST /api/tasks HTTP/1.1
Host: localhost:8080
Content-Type: application/json

{"title":"Learn Spring"}

# Expected response:
# 201 Created
# Location: /api/tasks/1
# {"id":1,"title":"Learn Spring","done":false}

What to expect

Implement this contract in the REST and persistence sections.

YOUR TURN

Put it into practice

  1. 01Design list, read-one, create, update, and delete routes.
  2. 02Choose statuses for a missing ID and empty title.
  3. 03Explain why GET should not create data.

Pass a quiz or complete a lab to check today’s streak. Each lesson counts once per day, including when you review it later.

UNDER THE HOOD

Build the mental model

Model the API around resources and observable behavior. HTTP status and headers are part of the contract, not decoration.

  1. 01GET must not create business state. PUT and DELETE have idempotent intended effects, although response statuses can differ on repeats.
  2. 02201 should identify the created resource, commonly with Location. 204 has no response body. Return errors consistently rather than embedding failure in a 200 response.
  3. 03A timeout leaves the client uncertain whether a mutation happened. For retryable creation workflows, design an idempotency key rather than assuming POST retries are harmless.

A mistake worth avoiding

Do not use GET for delete just because it is easy to click.

DEBUGGING ROOM

Something broke. Where do you look?

A client retries a timed-out create request and gets two tasks.

Before revealing the diagnosis, write down your first investigation step.

CHECK YOUR UNDERSTANDING

Which response should not carry a response body?

Choose one answer

BUILD IT YOURSELF

Write an API contract before code

  1. 1.Document routes, request DTOs, statuses, and errors.
  2. 2.Define pagination parameters and limits.
  3. 3.Describe what a retried create request should do.

Acceptance checklist

Lab completion is your self-report. Knowledge checks do not certify project quality.

RETRIEVE IT FROM MEMORY

What can a client conclude after a network timeout?

Revisit this lesson in three days after a successful check or lab.

Ready for the next step?

Describe an HTTP exchange independently of annotations.

Reading is separate from passing a knowledge check or completing a lab.

Go deeper · official references