How web services talk: HTTP and JSON

Spring Boot · Essentials · 10 min

A Spring Boot answers HTTP requests all day; every later lesson assumes these words.

When you open a weather app, it asks a computer somewhere for today's forecast and shows the answer. The program that asks is the client. The program that waits for questions and answers them is the server. Most of what you build with Spring Boot is a server: a program that keeps running and answers other programs.

They talk using HTTP, the same rules use. Every exchange is one request from the client followed by one response from the server, like a letter and its reply.

A request says where it is going with a URL, a web address such as http://localhost:8080/api/books/7. The last part, /api/books/7, is the path: which thing you want.

localhost is the name your computer uses for itself, handy while developing. 8080 is the port: a numbered door on that computer, so several servers can run side by side, each listening at its own number.

Anything after a ?, as in /api/books?page=2, is the query string: extra name=value options for the request.

Each request also has an HTTP method, a verb saying what to do: GET reads something, POST creates something new, PUT replaces it, PATCH changes part of it, and DELETE removes it.

Every response starts with a status code, a three-digit number saying how it went: 200 OK, 201 created, 204 done with nothing to send back, 400 the request was wrong, 404 not found, 500 the server failed. Codes in the 400s mean the client made a mistake; 500s mean the server did.

The data itself travels in the request body (or response body), usually as JSON: a text format for structured data, like {"id": 7, "title": "Dune"}. Names are in quotes, values follow a colon, and [ ] holds a list.

Requests and responses also carry headers, extra Name: value lines. Content-Type: application/json says the body is JSON.

A program that offers operations to other programs is an API; one reached over HTTP is a web API. Each method-plus-path it answers, like GET /api/books/7, is an endpoint. The curl command lets you call any endpoint from a terminal.

Example

# GET: read book 7 (-i also prints the status line and headers)
curl -i http://localhost:8080/api/books/7
# HTTP/1.1 200
# Content-Type: application/json
#
# {"id":7,"title":"Dune","author":"Herbert"}

# POST: create a book, sending JSON in the request body
curl -i -X POST http://localhost:8080/api/books \
     -H 'Content-Type: application/json' \
     -d '{"title":"Emma","author":"Austen"}'
# HTTP/1.1 201
# Location: http://localhost:8080/api/books/8

# A book that doesn't exist
curl -i http://localhost:8080/api/books/999
# HTTP/1.1 404

Remember

  • A client sends a request; a server sends back a response
  • A request has a method (GET, POST, PUT, PATCH, DELETE) and a URL
  • The status code says how it went: 2xx success, 4xx client mistake, 5xx server failure
  • Data travels as JSON in the body; headers describe it

Watch out for

  • Treating every error as the server's fault: a 4xx status means the request itself needs fixing.
New words in this lesson (2)
web app
An application used through a browser, such as webmail or an online spreadsheet.
browser
The app you use to visit websites, like Chrome, Firefox or Safari; it downloads pages and runs their code.

Check yourself

  1. A client asks GET /api/books/42 and no such book exists. Which status code fits best?
  2. Which HTTP method should a client use to create a new book?

Sign in to answer, see the explanations, and get this lesson back as a quick review later.

Official docs: spring.io/guides/gs/rest-service

Builds on

Nothing: this is a foundation.

Unlocks