Spring Boot初めてでもOK！最短でREST APIを1本動かす方法

Spring BootでREST APIを作りたいのに、情報が多すぎて「え、結局どこから？」ってなってませんか？わかります。そこでこの記事は、最短ルートで“APIを1本動かすことだけに全集中します。

今回のゴールはこれです👇

TODO APIを3本（追加・一覧・削除）作って、curlかPostmanで動くのを確認する。

難しい設計の話はあとでOKです。まずは「動いた！」を体験しましょう。

まず完成の姿（これが動けば勝ちです）

• POST /api/todos：TODOを追加する
• GET /api/todos：TODO一覧を取る
• DELETE /api/todos/{id}：TODOを消す

そして確認は以下をコピペすることで実施できます👇

# 追加
curl -X POST http://localhost:8080/api/todos \
  -H "Content-Type: application/json" \
  -d '{"title":"牛乳を買う"}'

# 一覧
curl http://localhost:8080/api/todos

# 削除（idは例）
curl -X DELETE http://localhost:8080/api/todos/1

読み終わるとできること

• REST APIの「最低限のルール」（GET/POST/DELETE、URLの形、ステータスコード）をサクッと理解できます
• Spring Bootで Controller / Service / Repository の役割分担ができます
• DTOでJSONの受け取り＆返し方がブレなくなります
• 404/400/500の返し方をテンプレで固定できます
• 必要なときだけ CORSを最小設定できます

「ちゃんと理解してから…」も大事ですが、最初はそれで止まりがちです。なのでこの記事は、理解はあとから追いつく前提でOKにしてあります。

REST APIは「3つだけ」覚えればOK

RESTって聞くと急にむずかしそうですが、最初はガチで 3つだけ 覚えれば大丈夫です。

それは

• やること（GET/POST/DELETE）
• URLの形
• 返す番号（ステータスコード）

の3点セットです。

ここを押さえると、RESTのモヤが一気に晴れます。

GET/POST/DELETEを日本語にすると？

まずこれを固定しちゃいましょう。APIはだいたいこの3つで回ります。

• GET＝見る（一覧を取る、1件を取る）
• POST＝増やす（新しく作る）
• DELETE＝消す（削除する）

今回のTODOなら、

見る＝GET（一覧）／増やす＝POST（追加）／消す＝DELETE（削除） でOKです。

いきなりPUTとかPATCHとか出てきても、今日はスルーで大丈夫です。まず動かすのが最優先です。

URLの形は「名詞」でそろえる（/api/todos）

次はURLです。ここでやりがちなミスが「動詞をURLに入れる」パターンです。

• ❌ /getTodos（GETって言っちゃってる）
• ❌ /addTodo（やることがURLに入ってる）
• ✅ /api/todos（名詞でそろってる）

コツはシンプルで、URLは“モノの名前（名詞）”にするだけです。

そして「何をするか」はURLじゃなくて、GET/POST/DELETE が決めてくれます。

ステータスコードはまず3つ（200/400/404）

最後は「返す番号」です。いっぱいありますが、最初はこの3つで十分です。

• 200：OK（成功したよ）
• 400：リクエストが変（入力ミスだよ）
• 404：見つからない（そのIDないよ）

例えばTODO削除で、存在しないIDを消そうとしたら 404 が自然です。

逆に、JSONが壊れてる・必須項目が空みたいな「入力がおかしい」は 400 です。

こんな感じで、RESTは「3つの型」を先に決めると迷子になりません。

まずはゴールを1つに絞る：TODO APIの仕様

ここで大事なのは「何を作るか」を先に固定しちゃうことです。

途中で「機能増やしたい…」「DBも入れたい…」ってなりがちなんですが、それやるとほぼ確実に迷子になります。

今回は最短で動かす回なので、TODO APIは最小セットの3本だけにします。

• URLは /api/todos で統一
• 操作は POST/GET/DELETE だけ
• データは超シンプルに id と title だけ

今回作るエンドポイント一覧（最小セット）

メソッド	URL	やること	返すもの（ざっくり）
POST	/api/todos	TODOを1件追加	追加されたTODO（id付き）
GET	/api/todos	TODO一覧を取得	TODO配列
DELETE	/api/todos/{id}	指定IDのTODOを削除	何も返さない（or メッセージ）

ポイントはこれです👇

URLは名詞で固定して、やることはメソッドで決める。（H2-1の復習ですね）

リクエストJSONとレスポンスJSONの完成見本

先に「完成形」を見せます。これが返ってくれば勝ちです。

追加（POST /api/todos）

リクエストJSON（送るやつ）

{
  "title": "牛乳を買う"
}

レスポンスJSON（返ってくる理想形）

{
  "id": 1,
  "title": "牛乳を買う"
}

一覧（GET /api/todos）

レスポンスJSON（配列で返す）

[
  { "id": 1, "title": "牛乳を買う" },
  { "id": 2, "title": "郵便局に行く" }
]

削除（DELETE /api/todos/1）

削除は「返すもの」に迷いやすいんですが、最短ならこれでOKです。

• 成功したら ステータスだけ返す（例：200 or 204）
• ボディ（JSON）は なしでもOK

例：

• 200 OK（成功）
• 404 Not Found（そのIDがない）

役割分担テンプレ：Controller/Service/Repository/DTO/Entity

Spring BootでREST APIを作るとき、いちばん詰まりやすいのがここです。

「どこに何を書けばいいんでしたっけ…？」ってなって、Controllerが巨大化して爆発します。なので最初から、役割をテンプレで固定しちゃいます。

結論だけ先に言いますね。

• Controller：受付
• Service：ルール（やること）
• Repository：保管
• DTO：外に見せる箱（JSONの形）
• Entity：中の都合の箱（DBの形）（※今回はDBなしなので“登場少なめ”）

Controller＝受付、Service＝ルール、Repository＝保管

たとえ話でいきます。TODOアプリを「お店」だと思ってください。

• Controller＝受付
  お客さん（リクエスト）が来たら受け取って、必要なら軽くチェックして、Serviceに渡します。
  返すときも「はい、これです（レスポンス）」って渡す役です。
• Service＝ルール
  “このアプリとしてどう動く？”の中心です。
  例：追加したらIDを振る、存在しないIDはエラーにする、みたいな判断はここ。
• Repository＝保管
  データをしまう・取り出す係です。
  今回はDBなしなので、メモリ（ListとかMap）に入れておく係になります。

これで「置き場所」が決まるので、迷いが減ります。

やってはいけない例（これが沼の入口です）

• ❌ Controllerに全部書く（保存もルールも例外処理も全部）
  → 最初は動くんですが、すぐ読めなくなります。

“動かすために雑に書く”のと、“置き場所を決めずに書く”のは別問題なので、役割分担だけは最初からやっておくのがコスパ最強です。

DTOとEntityは分ける（結論：最初からDTO推し）

ここも迷うポイントですが、結論はこれです。

最初からDTOで返してください。（強めに言い切ります）

理由はシンプルで、DTOを分けておくと後で困らないからです。

• Entity（DB用）をそのまま返すと、あとで項目が増えたときに
  「え、これ外に出してよかったっけ？」問題が起きます
• レスポンスの形（JSON）は、アプリの外との約束です
  → ここは DTOで固定すると安全です
• 今回はDBなしでも、DTOを使うだけで「APIっぽさ」が一気に出ます

イメージはこんな感じです👇

• CreateTodoRequest（受け取るDTO）
  title だけ
• TodoResponse（返すDTO）
  id と title

Entityは本来DBとセットで出てくるので、今回は「将来こういうのがあるよ」くらいでOKです。

最初はDBなし（メモリ保管）でOK

「Repositoryって言うならDBいる？」って思いますよね。いりません。最初はメモリで十分です。

• 目的は REST APIを1本動かすこと
• DBを入れると、設定・接続・テーブル・エラー…で寄り道が増えます
• まずは List や Map に保存して、動く流れを作ったほうが早いです

あとからDBに変えるときも、Repositoryに閉じ込めておけば差し替えやすいです。

つまり、いまメモリで作るのは“手抜き”じゃなくて“順番”です。

実装ステップ：Spring Bootで最短構成を作る

ここは「手を動かして、動いた！」まで一直線でいきます。

0円でも開始可能です（こだわる人は有料IDEもアリ）。

Spring Bootは今だと4系も出てますが、最低でもJava 17が必要です。

道具を用意（無料でOK）

• JDK：無料（Java 17以上）
• IDE：無料〜有料（例：VSCode/IntelliJ Community＝無料、IntelliJ有料版＝快適）
• Spring Initializr：無料（ひな形作成）

Download the Latest Java LTS Free

Subscribe to Java SE and get the most comprehensive Java support available, with 24/7 global access to the experts.

www.oracle.com

https://azure.microsoft.com/ja-jp/products/visual-studio-code

azure.microsoft.com

https://start.spring.io

start.spring.io

プロジェクト作成（依存関係は最小）

Spring Initializrで Dependenciesは「Spring Web」だけにします。
作れたら起動して、ログに Started ... が出たら成功のサインです。

パッケージ構成（迷わない置き場所）

com.example.todo 配下にこれだけ作ります。

• controller / service / repository / dto

コピペで動くコード（Controller/Service/Repository）

dto/CreateTodoRequest.java

package com.example.todo.dto;
public record CreateTodoRequest(String title) {}

dto/TodoResponse.java

package com.example.todo.dto;
public record TodoResponse(long id, String title) {}

repository/TodoRepository.java

package com.example.todo.repository;

import com.example.todo.dto.TodoResponse;
import org.springframework.stereotype.Repository;

import java.util.*;
import java.util.concurrent.ConcurrentHashMap;
import java.util.concurrent.atomic.AtomicLong;

@Repository
public class TodoRepository {
  private final Map<Long, String> store = new ConcurrentHashMap<>();
  private final AtomicLong seq = new AtomicLong(0);

  public TodoResponse save(String title) {
    long id = seq.incrementAndGet();
    store.put(id, title);
    return new TodoResponse(id, title);
  }

  public List<TodoResponse> findAll() {
    return store.entrySet().stream()
        .sorted(Map.Entry.comparingByKey())
        .map(e -> new TodoResponse(e.getKey(), e.getValue()))
        .toList();
  }

  public boolean delete(long id) {
    return store.remove(id) != null;
  }
}

service/TodoService.java

package com.example.todo.service;

import com.example.todo.dto.TodoResponse;
import com.example.todo.repository.TodoRepository;
import org.springframework.stereotype.Service;

import java.util.List;

@Service
public class TodoService {
  private final TodoRepository repo;
  public TodoService(TodoRepository repo) { this.repo = repo; }

  public TodoResponse create(String title) { return repo.save(title); }
  public List<TodoResponse> list() { return repo.findAll(); }

  public void delete(long id) {
    if (!repo.delete(id)) throw new RuntimeException("Todo not found");
  }
}

controller/TodoController.java

package com.example.todo.controller;

import com.example.todo.dto.CreateTodoRequest;
import com.example.todo.dto.TodoResponse;
import com.example.todo.service.TodoService;
import org.springframework.http.ResponseEntity;
import org.springframework.web.bind.annotation.*;

import java.util.List;

@RestController
@RequestMapping("/api/todos")
public class TodoController {
  private final TodoService service;
  public TodoController(TodoService service) { this.service = service; }

  @PostMapping
  public ResponseEntity<TodoResponse> create(@RequestBody CreateTodoRequest req) {
    return ResponseEntity.ok(service.create(req.title()));
  }

  @GetMapping
  public List<TodoResponse> list() { return service.list(); }

  @DeleteMapping("/{id}")
  public ResponseEntity<Void> delete(@PathVariable long id) {
    service.delete(id);
    return ResponseEntity.noContent().build();
  }
}

JSONの受け取りと返し方：RequestBodyとResponseEntity

REST APIでいちばん不安になりやすいのが「JSONってどう受け取って、どう返すの？」問題です。

ここはコツがあります。
“受け取る箱”と“返す箱”をDTOで固定して、Controllerはそれを使うだけにすると一気にラクになります。

POSTで受け取る（@RequestBodyの付け忘れ注意）

POSTでJSONを受け取るときは、Controllerの引数に @RequestBody を付けます。これ、忘れると「titleがnull」「400になる」みたいな事故が起きやすいです。

@PostMapping
public ResponseEntity<TodoResponse> create(@RequestBody CreateTodoRequest req) {
  var created = service.create(req.title());
  return ResponseEntity.ok(created);
}

「JSONをJavaの箱（DTO）に入れてね」の合図が @RequestBody だと思ってください。

返すときは「箱」をそろえる（DTO）

受け取り用DTOと、返す用DTOは分けちゃいましょう。

• 受け取る：CreateTodoRequest（例：titleだけ）
• 返す：TodoResponse（例：idとtitle）

こうすると、あとで項目が増えても「外に出す形（レスポンス）が勝手に変わる」事故を防げます。
APIは外との約束なので、返す箱は特にDTOで固定が安心です。

201/204も使うと気持ちいい（でも必須じゃない）

ステータスコードは、最短でいくなら 200で統一でもOKです。
ただ、少しだけ“それっぽく”するならこの2つが気持ちいいです。

• 作った（POST成功）→ 201 Created
• 消した（DELETE成功）→ 204 No Content（返すものなし）

例：POSTを201にするならこんな感じです👇

@PostMapping
public ResponseEntity<TodoResponse> create(@RequestBody CreateTodoRequest req) {
  var created = service.create(req.title());
  return ResponseEntity.status(201).body(created);
}

エラー時にどう返す？404/400/500を「型」で固定する

APIって、成功より失敗の返し方で「ちゃんとしてる感」が出ます。

ここは迷わずテンプレ化しちゃいましょう。

コツは1つだけで、エラーのJSONの形（型）を固定します。

返すエラーJSONを決める（message/code）

まずはエラーの完成形をこれに決めます👇

{
  "message": "Todo not found",
  "code": "TODO_NOT_FOUND"
}

• message：人間が読んで分かる説明
• code：機械が見て判定しやすい短いID（あとでフロントが分岐しやすい）

DTO（箱）も用意します。

// dto/ErrorResponse.java
package com.example.todo.dto;
public record ErrorResponse(String message, String code) {}

@ControllerAdviceでまとめて返す流れ

次に、例外（エラー）を全部ここに集めて返す係を作ります。

Controllerに毎回try-catchを書くのはしんどいので、まとめて一発でいきます。

// exception/NotFoundException.java
package com.example.todo.exception;
public class NotFoundException extends RuntimeException {
  public NotFoundException(String message) { super(message); }
}

// exception/BadRequestException.java
package com.example.todo.exception;
public class BadRequestException extends RuntimeException {
  public BadRequestException(String message) { super(message); }
}

// exception/GlobalExceptionHandler.java
package com.example.todo.exception;

import com.example.todo.dto.ErrorResponse;
import org.springframework.http.ResponseEntity;
import org.springframework.web.bind.annotation.*;

@ControllerAdvice
public class GlobalExceptionHandler {

  @ExceptionHandler(NotFoundException.class)
  public ResponseEntity<ErrorResponse> handleNotFound(NotFoundException e) {
    return ResponseEntity.status(404).body(new ErrorResponse(e.getMessage(), "TODO_NOT_FOUND"));
  }

  @ExceptionHandler(BadRequestException.class)
  public ResponseEntity<ErrorResponse> handleBadRequest(BadRequestException e) {
    return ResponseEntity.status(400).body(new ErrorResponse(e.getMessage(), "BAD_REQUEST"));
  }

  @ExceptionHandler(Exception.class)
  public ResponseEntity<ErrorResponse> handleOther(Exception e) {
    return ResponseEntity.status(500).body(new ErrorResponse("Unexpected error", "INTERNAL_ERROR"));
  }
}

よくある失敗→どう直す？（例：IDがない）

失敗例：DELETEで存在しないIDを消したのに、なぜか500になる

これ、だいたい「見つからないのに例外を投げてない」か「RuntimeExceptionのまま投げてる」パターンです。

直し方はこれです👇

• Serviceで「ないならNotFoundExceptionを投げる」
• Advice側で404に変換して、エラーJSONを返す

例：Service側（削除）をこうします。

public void delete(long id) {
  if (!repo.delete(id)) throw new NotFoundException("Todo not found");
}

これで、404/400/500が毎回同じ形で返るので、動作確認もデバッグもめちゃ楽になります。

次はその動作確認を、curlとPostmanのコピペで一気に終わらせます。

動作確認：curlとPostmanは「これだけ」でOK

ここまで来たら、あとは「本当に動いてる？」を確認するだけです。

動作確認は凝らなくてOKで、curlはコピペ3本、PostmanはURL入れてSendで終わります。

つまずいても、見る順番さえ決めておけば復帰できます。

curlコピペ集（追加→一覧→削除）

まずアプリを起動して、http://localhost:8080 で動いてる前提です。

追加（POST）

curl -X POST http://localhost:8080/api/todos \
  -H "Content-Type: application/json" \
  -d '{"title":"牛乳を買う"}'

成功すると、だいたいこんなJSONが返ります👇（idは環境で変わります）

{ "id": 1, "title": "牛乳を買う" }

一覧（GET）

curl http://localhost:8080/api/todos

こんな感じで配列が返ればOKです👇

[
  { "id": 1, "title": "牛乳を買う" }
]

削除（DELETE）

curl -X DELETE http://localhost:8080/api/todos/1

成功なら 204（ボディなし）になる想定でしたね。
もし存在しないIDなら、H2-6で決めたエラーJSONで 404 が返るはずです👇

{ "message": "Todo not found", "code": "TODO_NOT_FOUND" }

Postmanは「URL入れてSend」だけ

Postmanは難しく考えなくてOKで、最短はこれです。

• New（または＋）でリクエスト作成
• 上の欄に URLを貼る（例：http://localhost:8080/api/todos）
• POSTのときだけ Body → raw → JSON を選んで、これを貼って Send { "title": "郵便局に行く" }

GETはURL貼ってSend、DELETEはメソッドをDELETEにしてSend。以上です。

Postman: The World's Leading API Platform | Sign Up for Free

Accelerate API development with Postman's all-in-one platform. Streamline collaboration and simplify the API lifecycle f...

www.postman.com

つまずきチェックリスト（ポート/JSON/ログ）

動かないときは、順番をこれに固定してください。これだけで復帰率が上がります。

• まずログ
  • 起動時に Started ... が出てる？
  • エラーが出てたら、その行の周りに答えがあります
• 次にURL
  • localhost:8080 になってる？（8081とかにズレてない？）
  • /api/todos の s 抜けてない？（地味に多いです）
• 最後にJSON
  • Content-Type: application/json を付けた？（curlのPOST）
  • JSONのカッコ {} やダブルクォート " 崩れてない？

CORSと次の一歩：必要なときだけ最小で設定する

CORSが要るのは「フロントが別住所」のとき

CORSが必要になるのは、ざっくり言うと フロント（ブラウザ）が別の住所からAPIを呼ぶときです。

例：フロントが http://localhost:3000、APIが http://localhost:8080 みたいに ポートが違うだけでも「別住所」扱いになります。逆に、同じ住所なら気にしなくてOKです。

まずは許可を小さく（特定のURLだけ）

最初から「全部OK」はおすすめしません。許可する相手（Origin）と、許可するURL（Path）を絞るのが安全です。

// config/CorsConfig.java
@Configuration
public class CorsConfig implements WebMvcConfigurer {
  @Override
  public void addCorsMappings(CorsRegistry registry) {
    registry.addMapping("/api/todos/**")
      .allowedOrigins("http://localhost:3000")
      .allowedMethods("GET","POST","DELETE");
  }
}

これで「TODOだけ」「このフロントだけ」許可、という最小構成になります。

次にやると伸びる3つ（DB/H2・入力チェック・API一覧）

動いたら、次はこの3つだけやると一気にレベルアップします。

• DBを入れる（学習用ならH2）：無料。メモリ卒業して「保存できるAPI」になります
• 入力チェック：titleが空のときは400、みたいな“お作法”が整います
• API一覧を出す（Swagger UI系）：無料〜有料。チーム開発だと特に便利です

※道具カテゴリと価格帯目安

• 組み込みDB（学習用）：無料（例：H2）
• API一覧表示ツール：無料〜有料（例：Swagger UI系）

よくある質問