【Rails】REST

はじめに

こんにちは。アメリカ在住で独学エンジニアを目指している Taira です。

API の勉強をしていると、必ず出てくるのが REST。Rails チュートリアルを進めて何回もこの単語を見ましたが結局わからないまま、、、
そして、飛行機に乗っている時間のある時に「Web を支える技術」でRESTについて言及されており再度学習する機会がありました。

この記事では、REST の6つの原則をわかりやすく整理しつつ、実際の API 設計にどう活かせるのかを紹介します。

---

REST の6つの原則（アーキテクチャ制約）

1. クライアント・サーバー (Client-Server)

• クライアントとサーバーの責務を分ける。
• 例: React がクライアント、Rails がサーバー。
• → UI とデータ処理が分かれることで、保守性や拡張性が上がる。

2. ステートレス (Stateless)

• サーバーはセッション情報を保持しない。
• 毎回リクエストに必要な情報（例: 認証トークン）を含める。
• → サーバーを横に増やしても問題なく動く。

3. キャッシュ可能 (Cacheable)

• レスポンスがキャッシュ可能かを明示できる。
• 例: Cache-Control: max-age=3600
• → 無駄な通信を減らしてパフォーマンス改善。

4. 統一インターフェース (Uniform Interface)

REST の肝となる部分。以下の要素を満たす：

• リソースの識別: /users/1
• 表現による操作: JSON や XML でデータをやり取り
• 自己記述的メッセージ: Content-Type などで意味がわかる
• HATEOAS: レスポンスにリンクを含め、次の操作を導く

5. 階層化システム (Layered System)

• クライアントは中間サーバー（ロードバランサー、プロキシ、キャッシュ）を意識しない。
• → セキュリティやスケーラビリティを強化できる。

6. コード・オン・デマンド (Code on Demand) [任意]

• サーバーがクライアントにコード（例: JavaScript）を送って実行させることも可能。
• 実際の API 設計ではあまり意識されない。

---

実務でよく意識するポイント

• URI 設計はリソースを表現する形に

  • 良い例: /users/1/posts/2/comments
  • 悪い例: /getUser?id=1 や /updateUserName

• HTTP メソッドの役割を守る

  • GET: 取得
  • POST: 作成
  • PUT: 全体更新
  • PATCH: 部分更新
  • DELETE: 削除

• Rails の場合

  • resources :users と書くだけで RESTful なルーティングが自動生成される。

---

REST のメリット

• 直感的に API を理解しやすい。
• キャッシュや階層化でパフォーマンスが向上する。
• クライアントとサーバーが分離されて開発効率アップ。

---

REST の限界と代替手段

• 複雑なバッチ処理や集計は表現しにくい。
• 双方向通信（チャットやストリーミング）には不向き。
• その場合は GraphQL や gRPC を検討するのが現実的。

---

まとめ

• REST は「リソースを URL と HTTP メソッドで扱う」だけじゃなく、6つの原則を満たすアーキテクチャスタイル。
• 特に「統一インターフェース」「ステートレス」「キャッシュ可能」は実務で意識する場面が多い。
• RESTful をベースにしつつ、要件に合わせて別の手法も選べるようになると応用が効く。