0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

WebAPI と REST

Last updated at Posted at 2025-06-10

[RESTの一次情報:Roy Fielding's doctoral dissertation]

Webエンジニアを目指すとWeb API と REST という言葉がよく出てきます。
本記事では、これについてキャッチアップします。

まず、用語を整理します。

  • Web

    • World Wide Webの略
    • なんとなく分かると思うので割愛WWWについてはこちら
    • 一番わかりやすくいうと、よくいうネット(インターネット)
  • API

    • Application Programming Interfaceの略
    • つまり、アプリプログラム繋ぎ目
    • あるアプリ例えばInstagramから、外部のプログラム例えばgoogle map、を繋ぐ これをAPIという。
  • Web API

    • Webの文脈における、API
    • つまり、インターネット(Web)を使用する際に、Webアプリ外部プログラム繋ぐ役割をするもの
  • REST

    • REpresentational State Transferの略
    • 具象化された 状態転送
    • 以下、JSONで記述した具象化された状態の例である。これを転送する
{
  "id": 123,
  "name": "Alice",
  "email": "alice@example.com",
  "age": 25,
  "createdAt": "2023-06-01T10:00:00Z"
}
概念 JSON内で対応する部分
具象化された JSON形式(構造化され、人が理解でき、機械も読める)
状態 name, email, age, createdAt などの属性
転送 ネットワークを通じて、クライアントへこの「状態」が届く
  • REST API
    • 「RESTの原則にしたがって作られたAPI」のこと
    • クライアント(例:ブラウザやスマホアプリ)とサーバーが、リソース(例:ユーザー、投稿、商品など)をやりとりするための窓口
    • 特徴は、「状態(データ)を、具象化された形(JSONなど)で、転送してやりとりする」という点
    • 例えば、GET /users/123 と送ると、そのユーザーの状態(データ)を表現したJSONが返ってくる

📦 REST APIの例:
リクエスト

GET /users/123

レスポンス

{
  "id": 123,
  "name": "Alice",
  "email": "alice@example.com"
}

ここでは「users/123というリソースの状態」を、「JSON形式で具象化」して、「ネットワークで転送」している

REST APIのイメージまとめ 🎨

  • レストランの注文のようなもの。
  • 客(クライアント)は「ハンバーガーをください(GET /burgers/1)」と注文し、
  • 店(サーバー)は「この状態のバーガーです」と写真(JSON)を返す。
  • 客は直接キッチンに入らず、写真(具象化された状態)でやり取りする。

👦 REST=「具象化された状態の転送(Representation of State Transfer)」とわざわざいうくらいだから、RESTではない設計思想を持つAPIもあるってことかな?

結論:YES
例えば、以下がある。

  • GraphQL
  • RPC
  • gRPC
スタイル 状態を具象化? 転送の焦点 イメージ(レストラン) 簡単なコード例
REST ✅ yes 状態(リソース) メニューから「カレー」を注文し、決まった具材すべてが届く(ルー・肉・じゃがいも・にんじん) GET /menu/curry
→ { name: "Curry", ingredients: ["roux", "meat", "potato", "carrot"] }
GraphQL ⚠️ yes(部分的) 状態(クエリベース) 「カレーのルーとじゃがいもだけください」と注文。必要なものだけを取得できる graphql<br>{ curry { roux, potato } }<br>→ { curry: { roux: true, potato: true } }
RPC ❌ no 処理(操作) ウェイターに「水を持ってきて」と操作そのものを依頼 POST /bringWater
→ { status: "ok" }
gRPC ❌ no 処理(高速・内部通信) 厨房スタッフ同士が「皿洗って」などを高速・効率的にやり取り service Kitchen { rpc WashDishes(WashRequest) returns (WashResponse); }

🥇 REST:具象化された状態の転送

  • サーバーが「あるリソースの状態のスナップショット(representation)」を返す
  • クライアントはその状態を取得・変更する
📦 例:
GET /users/123 → { "name": "Alice", "age": 25 }

🧠 イメージ:
展示室の写真を受け取って、編集してまた送り返す

🥈 RPC(Remote Procedure Call):関数呼び出し型のAPI

  • サーバーの「操作(関数)」を直接呼び出す感覚
  • 状態の具象化は意識せず、「この処理をして」と伝える
📦 例:
POST /createUser with body { "name": "Alice", "age": 25 }

🧠 イメージ:
電話をかけて「この作業やって」と口頭で依頼する
🔁 状態の転送ではなく、「動作」のリクエストが中心

🥉 GraphQL:クライアント主導で状態の選択的取得

  • クライアントが必要なデータ構造を宣言して取得
  • 状態は転送されるが、具象化の粒度はクライアントが決める
📦 例:
query {
  user(id: 123) {
    name
    age
  }
}
🧠 イメージ:
レストランでオーダーシートに「欲しいものだけ」を書いて出す

✔️ 「状態を転送」はするが、「具象化の仕方」がRESTとは異なる

🏅 gRPC:型安全&高速なRPC通信(主にマイクロサービス間)

  • プロトコルバッファ(protobuf)を使ってバイナリ形式で通信
  • RESTよりも**「内部システム間の手続き呼び出し」に特化**
  • 状態の概念というより、関数を安全に・効率的に呼ぶ
📦 例:
UserService.CreateUser() という関数を直接呼び出す

🧠 イメージ:
高性能な社内メッセンジャーで一瞬で指示を送る
0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?