Webアプリに限らず、今日のインターネット利用でほぼ無意識に利用されているHTTP通信、今回はそのHTTP通信を介して利用される「REST」な「API」について私なりに記事を書いてみたいと思います。
APIとは
APIとは自社サービスやその機能を第三者が再利用・拡張することができるようにしたインターフェースを指します。
- これにより、自社サービスを元にした関連サービスの拡充が促進され、サービス自体の発展に繋がります。
- 一方で第三者が自社のリソースを使用し易くなる為、リソースが圧迫される恐れがあります。この対策としては第三者のアクセスを一定的に制限するレートリミット対策が有効です。
このAPIをWebアプリ上で公開しているのが「Web API」になります。
RESTとは
RESTは「REpresentational State Transfer」の略で、分散型システムにおける設計ルールを定めたものです。
分散型システムというのは、サーバサイドにおけるwebの三層構造がよく例に挙げられ、
- HTMLを生成するプレゼンテーション層
- クライアントの要求や、データアクセスを相互に行うアプリケーション層
- データの取得・管理を行うデータベース層
が相互に連携し合う中で、統一的な設計ルールを定めたものになります。
REST原則の中で特徴的なものは以下になります。
階層化システム
- サーバサイド内の各システムの役割を決め独立させることで、各システムを効率よく使用することができる。
コードオンデマンド
- クライアント側がサイトのコードをダウンロードして手持ちのローカル環境で実行できる事。これにより、サーバ側で新しいプログラムを随時構築することで、常に新しいコードをクライアント側へ提供可能。
統一インターフェース
- URIで指定されたリソースへの操作を統一、動作を含まず限定的なインターフェースで実行可能。
ステートレス
キャッシュ制御が可能
- クライアント側に情報のキャッシュを持たせることにより、余分な通信が排除されリソースや拡張性が向上する。
以上の原則を遵守して設計されたシステムをRESTfulなシステムといいます。このREST原則に沿って設計されたAPIが「REST API」と言えます。
REST原則沿った設計は、URIを使用したHTTP通信の中身であるHTTPリクエスト・HTTPレスポンスの内容を、統一された書き方で実装することにより実現されます。
URI設計
記述されたURIはリソースを表し、HTTPメソッドはそのリソースに対する操作を表します。
REST制約に沿ったURI・HTTPメソッドの例
- リソースにmovieを指定し、HTTPメソッドを使用したCRUD操作例になります。
| URI | HTTP method |
|---|---|
| POST /movies | POST |
| GET /movies/1 | GET |
| PUT /movies/1 | PUT |
| DELETE /movies/1 | DELETE |
REST設計では、URIの記述に重要なルールがあります。
- URI自体は短く簡潔に
- 単語の記述を省略形にしない
- 全て小文字で記載すること
- 単語同士を繋げる場合はアンダースコアではなく、ハイフンを使用すること
- 単語は複数形を使用すること
- (日本語のような)エンコードを必要とする文字列を使用しない
- サーバ側のアーキテクチャ(使用プログラム言語の文法等)をURIに記述しない
- クエリパラメータとパスパラメータの使い分け
- クエリパラメータ(末尾にあるキーバリュー = 省略可能な場合に使用)
- パスパラメータ(URI中に埋め込まれるパラメータ=一意なリソースを表す場合に使用)
また統一された設計ルールを使用するにより、実装時の間違いを防ぐことが容易になります。
