JavaでWebシステムを構築していると、通信に関する内容を理解する必要が出てきたので、学習するついでにアウトプットする。「GET/POST通信」および「REST API」の概念について理解を深めるためのまとめ。
1. Webシステムの通信方式
Webシステムは基本的に HTTP や HTTPS という通信プロトコルを利用する。
クライアント（Webブラウザなど）が「リクエスト（要求）」を出し、サーバーが「レスポンス（応答）」を返す。原則として、1つのリクエストには1つのレスポンスが対となる。
HTTPとTCP/IPの関係
HTTPは、信頼性の高い通信を行うために TCP というプロトコルを用いている。（厳密には「TCP/IP」という階層モデルに基づいてデータが運ばれる。）
※まあわかりにくいので、「自分がリクエストを投げ、相手（サーバー）からレスポンスが返ってくる」 という基本構造を押さえておけばよいかと、、
-
アプリケーション層 (HTTP): データ（便箋）を書く。
-
トランスポート層 (TCP): 書留の封筒に入れる（確実に届けるため）。
-
インターネット層 (IP): 宛先住所（IPアドレス）を書く。
-
ネットワークインターフェース層: 物理的な通信網（トラックやWi-Fi）に乗せる。
2. GET / POST通信
HTTP通信において、目的によって使い分けられる代表的なメソッド。
Get
-
webサーバーからデータを取得する
-
データは URL（クエリパラメータ） に付与される
-
検索、ページ表示など、サーバーの状態を変えない操作に使う
Post
-
webサーバーに新しいデータを送信して、作成する
-
ログイン情報や個人情報など機密情報の送信に使用
-
**フォーム送信、会員登録、投稿など、サーバーに書き込みが発生する操作に使う
特徴の比較
| 項目 | GET | POST |
|---|---|---|
| 目的 | データの取得 | データの新規作成・送信 |
| データの場所 |
URLの末尾（クエリパラメータ） 例: ?id=1&word=java
|
リクエストボディ（Body） 封筒の中身に入れるためURLには出ない |
| 用途 | 検索、ページ表示など | フォーム送信、会員登録、ログインなど |
| Javaでの取得 |
request.getParameter()等 |
request.getBody()等の処理が必要 |
※補足: REST API等の設計では、更新には
PUT、削除にはDELETEを使うことが多いが、従来のWebフォームではPOSTが書き込み全般に使われる。
重要な概念：冪等性と安全性
技術的な定義において、以下のように区別される。
-
冪等性(べきとうせい) (Idempotent):
- 1回実行しても100回実行しても、結果（サーバーの状態）が同じになる性質。
-
安全性 (Safe):
- 操作を行っても、サーバーのデータが**書き換わらない（副作用がない/読み取り専用）**性質。
| メソッド | URL例 | 冪等性 | 安全性 | 理由 |
|---|---|---|---|---|
| GET | /home |
あり | あり | 何度見ても同じ画面で、データは破壊されない。 |
| POST | /register |
なし | なし | 連打するとデータが増殖し（冪等でない）、DBが更新される（安全でない）。 |
つまり、Getの通信は、"https://example.com" から home に移動するために "https://example.com/home" というように、URLに目的を表示してページの表示などを行うため、
何度やっても同じ結果が得られ（冪等で）かつページのデータは書き換わらない（安全）である。
対してPostの通信は、サーバーの情報を更新するのが目的なので、
何度やっても違う結果になり（冪等でない）、安全でない（更新するのでデータは書き換わる）
※補足: 冪等性は漢字が読めないので注意。
安全性は、セキュリティ的に安全という意味ではない。
3. API (Application Programming Interface)
Web APIは、「システムとシステムを連携させるための窓口」
自社システムで開発するのが困難な機能や、セキュリティリスクの高い処理を外部システムへアウトソースするために使われる。
具体例：ECサイトとStripe（広く使われている決済システム）の連携
自社でクレジットカード情報を持ちたくない場合、APIを利用する。
-
ECサイト: 「金額」＋「カード情報」＋**「APIキー（身元証明の鍵）」**を送信。
-
Stripe: 送信元を認証し、決済処理を実行。
-
Stripe: 「決済完了」の通知だけを返す。
-
ECサイト: 完了通知を受け取り、注文を確定する。
4. Web APIの主な種類
Web APIにもいろいろ種類があるみたい。
現在のWeb開発では以下の3つが主流
① REST API (現在主流)
Web（HTTP）の仕組みを最大限に活かした設計思想。
鉄則ルール
-
URLには「名詞（リソース）」のみを使う。（動詞は入れない）
-
動作は「HTTPメソッド」で使い分ける。
悪い例: /getUsers, /createUser （動詞が入っているため管理しづらい）
良い例: /users （名詞のみ）
リクエストの設計例
| メソッド | URL | 意味 | 日本語イメージ |
|---|---|---|---|
| GET | /users |
一覧取得 | 「ユーザーリストをください」 |
| POST | /users |
新規作成 | 「新しいユーザーを登録してください」 |
| GET | /users/1 |
詳細取得 | 「ID:1のユーザー情報をください」 |
| PUT | /users/1 |
更新 | 「ID:1のユーザー情報を書き換えてください」 |
| DELETE | /users/1 |
削除 | 「ID:1のユーザーを消してください」 |
レスポンス（ステータスコード）
結果は「数字」で判断する。
-
200番台 (成功):
200 OK,201 Created -
400番台 (クライアントのミス):
400 Bad Request(データ形式が変。),401 Unauthorized(認証切れ),404 Not Found(URLが見つからない) -
500番台 (サーバーのミス):
500 Internal Server Error
② GraphQL (新鋭・柔軟)
Meta（旧Facebook）が開発。RESTの課題（過剰取得・複数通信）を解決するために生まれた。
-
思想: 「クライアントが欲しいデータを指定する」（データクエリ指向）。
-
特徴:
-
エンドポイント（URL）は 1つだけ（例:
/graphql）。 -
リクエスト時に「ユーザーの名前だけ欲しい」と指定すれば、それだけが返ってくる。
-
複数のリソース（ユーザー情報＋投稿記事など）を1回の通信でまとめて取得できる。
-
③ gRPC (超高速通信)
Googleが開発。主にマイクロサービス間の通信で利用される。
-
思想: JSONではなく**バイナリデータ（機械語に近い形式）**で通信する。
-
特徴:
-
人間には読めないが、通信速度が極めて速い。
-
定義ファイル（Protocol Buffers）を用いて厳密に型を決める。
-
5. まとめ：APIスタイルの比較表
| 項目 | REST (現在主流) | GraphQL (柔軟) | gRPC (高速) |
|---|---|---|---|
| 思想 |
リソース指向 (URLでモノを指定) |
データクエリ指向 (欲しいデータを要求) |
手続き指向 (関数呼び出しに近い) |
| URL | 複数ある ( /users, /posts...) |
1つだけ | 1つだけ |
| データ形式 | JSON (テキスト) | JSON (テキスト) | Protocol Buffers (バイナリ) |
| 自由度 | サーバーが決める | クライアントが決める | 厳密な契約(定義)に従う |
| 主な用途 | Webサービス全般 | スマホアプリ、複雑なUI | マイクロサービス、サーバー間通信 |