ここまでの学習で、JavaScript の fetch を使ってサーバーからデータを取得する体験をしました。SQL では INSERT / SELECT / UPDATE / DELETE でデータを操作しました。次の Part では Spring Boot を使って、自分で API を作る側に回ります。
その前に、ブラウザとサーバーの間で何が行き来しているのかを短く整理します。ここで出てくる用語は Spring Boot の記事でそのまま使います。
リクエストとレスポンス
Web の通信は「ブラウザが要求を送り、サーバーが応答を返す」という往復で成り立っています。
- リクエスト(request) — ブラウザからサーバーへ送る要求。「このデータをください」「このデータを登録してください」といった内容
- レスポンス(response) — サーバーからブラウザへ返す応答。要求された結果のデータや、処理の成否を含む
この往復に使われる通信ルールが HTTP(HyperText Transfer Protocol)です。ブラウザのアドレスバーに http:// や https:// と表示されるのは、この通信ルールを使っているという意味です。
URL とエンドポイント
fetch で指定した URL を思い出してください。
https://jsonplaceholder.typicode.com/users/1
この URL は「jsonplaceholder.typicode.com というサーバーの /users/1 という場所」を指しています。サーバー側であらかじめ用意されたこの「場所」をエンドポイントと呼びます。
Spring Boot では、自分でエンドポイントを定義します。たとえば /items というエンドポイントを作れば、ブラウザや fetch から http://localhost:8080/items でアクセスできるようになります。
HTTP メソッド — 操作の種類を伝える
リクエストには「何をしたいか」を示す HTTP メソッドが付きます。よく使う4つと、データ操作(CRUD)の対応は次のとおりです。
| HTTP メソッド | 意味 | CRUD との対応 | SQL との対応 |
|---|---|---|---|
| GET | データを取得する | Read | SELECT |
| POST | データを新しく作る | Create | INSERT |
| PUT | データを更新する | Update | UPDATE |
| DELETE | データを削除する | Delete | DELETE |
fetch の記事では URL を指定するだけでデータを取得できました。メソッドを指定しなかった場合、fetch は自動的に GET を使います。POST や PUT を使うときは、fetch の第2引数でメソッドを明示します。Spring Boot の記事でその書き方を扱います。
ステータスコード — 結果を3桁の番号で伝える
レスポンスには、処理の結果を表す3桁の番号が付きます。これがステータスコードです。
| コード | 意味 | よくある場面 |
|---|---|---|
| 200 | 成功 | GET でデータが正しく返ってきた |
| 400 | リクエストに問題がある | 必須項目が足りない、形式が間違っている |
| 404 | 見つからない | 存在しない URL やデータを指定した |
| 500 | サーバー内部のエラー | サーバー側のプログラムにバグがある |
先頭の数字でおおまかな分類が分かります。2xx は成功、4xx はリクエスト側の問題、5xx はサーバー側の問題です。Spring Boot で API を作ると、自分のコードが返すステータスコードを選ぶ場面が出てきます。
JSON — ブラウザとサーバーが共有するデータ形式
fetch の記事で見た JSON をもう一度確認します。
{
"id": 1,
"name": "田中太郎",
"email": "tanaka@example.com"
}
JSON は、ブラウザとサーバーの間でデータを受け渡すための共通フォーマットです。テキストなので人間にも読め、ほとんどのプログラミング言語で扱えます。
Spring Boot で GET のレスポンスを返すと、Java のオブジェクトが自動的に JSON に変換されます。POST でデータを受け取るときは、JSON がリクエストに乗って届き、Java のオブジェクトに変換されます。この変換は Spring Boot が裏側で処理するので、自分で変換コードを書く必要はありません。
fetch と Spring Boot のつながり
ブラウザと Spring Boot の通信の流れです。
sequenceDiagram
participant B as ブラウザ(fetch)
participant S as Spring Boot
B->>S: HTTP リクエスト(メソッド + URL + JSON)
S->>S: 処理(データの取得・登録・更新・削除)
S->>B: HTTP レスポンス(ステータスコード + JSON)
- ブラウザが
fetchで HTTP リクエストを送る。メソッド(GET / POST など)、URL(エンドポイント)、必要ならデータ(JSON)を含む - Spring Boot がリクエストを受け取り、Java のコードで処理する
- Spring Boot が HTTP レスポンスを返す。ステータスコード(200 / 404 など)と、結果のデータ(JSON)を含む
fetch の記事では、他の誰かが作ったサーバー(JSONPlaceholder)にリクエストを送っていました。Spring Boot の記事からは、このサーバー側を自分で作ります。
REST — HTTP メソッドで操作を表す設計方針
REST は「HTTP メソッドと URL の組み合わせでデータ操作を表す設計方針」です。GET /items でデータ一覧を取得し、POST /items で新規作成する、といった形です。Spring Boot で作る API はこの REST の考え方に沿って設計します。
この回のまとめ
| 用語 | 一言で |
|---|---|
| HTTP | ブラウザとサーバーの通信ルール |
| リクエスト / レスポンス | 要求と応答の往復 |
| エンドポイント | サーバー側が用意した URL |
| GET / POST / PUT / DELETE | 操作の種類を伝える HTTP メソッド |
| ステータスコード | 結果を表す3桁の番号 |
| JSON | データの受け渡しに使うテキスト形式 |
| REST | HTTP メソッドと URL でデータ操作を表す設計方針 |
次の記事では Spring Boot プロジェクトを作成し、最初の GET エンドポイントを動かします。