UIと機能の通信（RPC/SOAP/REST/JSON）

• 日程: Day 3 / セッション 08
• 時間: [14:10-14:40]
• 形式: 座学
• ゴール: RPC・SOAP・RESTの違いを3つ以上の観点で説明でき、REST APIのリクエスト/レスポンスをJSON形式で書ける
• 学習形式: 対話型解説

前セッションで「データはRDBに永続化する」と学びました。では、そのデータをどうやって画面（UI）に届けるか？ 答えは「通信（Communication）」です。

UIと機能（API・ロジック）を分離する流れは、Day 2のモックアップ作成、Day 4の実装まで一貫した方針です。分離するからには、両者を繋ぐ「通信規約」が必要になります。

RPC、SOAP、RESTという3つの代表的な方式があります。それぞれ「何を、どんな形で送るか」のルールが違います。本セッションで、現代の主流であるREST + JSONを中心に学びます。

「ユーザーID 123 の情報を取る」処理を3方式で書いてみます。

RPC風（関数呼び出し）

POST /api
{ "method": "getUser", "params": { "id": 123 } }

SOAP（XML）

<soap:Envelope>
  <soap:Body>
    <getUser>
      <id>123</id>
    </getUser>
  </soap:Body>
</soap:Envelope>

REST（URI＋HTTPメソッド）

GET /users/123

REST が圧倒的にシンプルなのが分かります。

RESTは「リソース指向」。URLを見ただけで「何をしようとしているか」が分かるのが強みです。

Roy Fielding が2000年の博士論文で定義した「RESTful（REST制約に従う）」の主要原則。

1. リソース指向: すべてのデータをURIで識別する（/users/123）
2. HTTPメソッドで操作: GET（取得）、POST（新規）、PUT（更新）、DELETE（削除）
3. ステートレス: サーバはセッション状態を持たない（毎回必要情報を送る）
4. 表現と実体の分離: 同じリソースを JSON でも XML でも HTML でも返せる

REST API リクエスト/レスポンス例（JSON）

リクエスト:

POST /users HTTP/1.1
Host: api.example.com
Content-Type: application/json

{
  "name": "山田太郎",
  "email": "yamada@example.com"
}

レスポンス:

HTTP/1.1 201 Created
Content-Type: application/json
Location: /users/124

{
  "id": 124,
  "name": "山田太郎",
  "email": "yamada@example.com",
  "createdAt": "2026-06-16T13:00:00Z"
}

HTTPステータスコードで結果を伝えるのもRESTのルールです。

• 200 OK: 成功
• 201 Created: 新規作成成功
• 400 Bad Request: リクエストが不正
• 401 Unauthorized: 認証されていない
• 404 Not Found: リソースが存在しない
• 500 Internal Server Error: サーバエラー

JSON例

{ "name": "山田", "age": 30 }

XML例

<user><name>山田</name><age>30</age></user>

JSONのほうが約30%少ない文字数で同じ情報を表せます。

• WSDL（Web Services Description Language）: SOAPサービスの仕様書（XML）
• WADL（Web Application Description Language）: RESTサービスの仕様書（XML）
• 現代では: OpenAPI（旧Swagger）、AsyncAPI、GraphQL Schema などが主流

JSONを発明したダグラス・クロックフォードは「私はJSONを発明したのではなく、発見しただけだ」と言っています。彼はJavaScriptのオブジェクトリテラル記法をデータ交換に使うアイデアを2001年に提唱しました。「軽くて、人間も読めて、ほぼすべての言語でパースできる」というシンプルな設計が、20年以上経った今もWeb通信のデファクトスタンダードであり続けています。

RESTを提唱したRoy Fieldingは、博士論文を書いた当時、ちょうどHTTP/1.1の仕様策定にも関わっていました。彼は「Webがなぜ成功したか」を理論化する過程で、RESTという制約セットを発見したのです。RESTは「新しく作った技術」ではなく「Webの成功要因を抽出した原則」というのが正確です。

ここまでの内容で疑問があれば、AIに質問してみましょう。たとえば：

• 「PUTとPATCHの違いを、自分のテーマの例で説明して」
• 「GraphQLはRESTと比べて何が嬉しい？」
• 「自分のテーマでREST API を設計するとしたら、エンドポイントを5つ挙げて」

通信方式はRPC→SOAP→RESTと進化してきました。現代のWeb開発では「REST + JSON」が圧倒的主流です。URIでリソースを識別し、HTTPメソッドで操作する、というシンプルなルールがREST の強みです。

次のセッションでは、ここまで設計してきたシステムを「どこで実行するか（ネイティブ、Web、モバイル、クラウド）」を考え、実際にcurlでHTTPリクエストを送ってみます。

• RPC・SOAP・RESTの違いを3つ以上の観点で説明できますか？
• REST APIのGET/POST/PUT/DELETEをそれぞれ用途と例で説明できますか？
• JSONで name=山田、age=30 のオブジェクトを書けますか？

• 参考リンク: Roy Fielding『Architectural Styles and the Design of Network-based Software Architectures』、『Webを支える技術』山本陽平
• 発展課題: 自分が知っているWebサービス（Twitter、GitHub等）のAPIドキュメントを1つ読み、RESTfulか判定してみる