RESTはWebサービスや Webアプリケーション設計の思想です。REST設計思想に従っているAPIは、REST APIとも呼ばれています。REST設計思想は、すでに全世界で普及されていて、多くの開発者に利用されています。RESTはAPIの設計思想として、APIをどのように設計するかをきちんと規定しています。その中で、エンドポイントのURLに対する規定もあります。本文では、REST APIのURLの設計方法および注意事項を皆さんに紹介していこうと思います。
shimizu chioka
REST（Representational State Transfer）とは
REST（Representational State Transfer）は、Webアーキテクチャのスタイルの1つであり、Web上でリソースを表現し、アクセスするための設計原則の集合体です。RESTは、HTTPプロトコルに基づいており、Webの性質に合わせたシンプルな設計が特徴です。RESTは、クライアントとサーバーの間でデータをやり取りするための一連の原則を定義しています。RESTには、リソースの識別、リソースの表現、ステートレスな通信、キャッシュの利用、統一インターフェースなどが含まれます。
例えば、Webサイトにアクセスする場合、WebブラウザからWebサーバーにHTTPリクエストを送信し、WebサーバーからHTTPレスポンスを受け取ります。このような通信の場合、RESTの原則が適用されています。
主なREST APIの設計原則
一般的には、REST設計思想には4つの主な設計原則があります。次は、これら4つの設計原則を1つずつ詳しく解説していこうと思います。
アドレス可能性
これはURIを使ってリソースに対して一意のアドレスを割り当てることを意味します。例えば、https://api.example.com/users/12345のように、ユーザーを表すリソースに一意のIDを含んだURIを割り当てることができます。アドレス可能性によって、リソースを参照および操作するための手段が提供されます。
統一したインターフェース
RESTではHTTPプロトコルという標準化されたインターフェースを使うことで、アプリケーション間での相互運用性を高めます。HTTPメソッドの使い分け(GET、POST、PUT、DELETEなど)によって、共通したインターフェースでさまざまな操作を実現できます。
ステートレス状態
これはサーバがクライアントのコンテキストや状態を保持しないことを意味します。したがってクライアントはリクエストごとに完全な情報を送信する必要があり、セッションIDやログイン状態などはクライアント側で管理します。これによりサーバのスケーラビリティが向上します。
shimizu chioka
接続性
これはクライアントとサーバが論理的に通信可能である必要があるということです。RESTではインターネット上の接続を利用するので、高い接続性を実現できます。
このようなREST APIの設計原則に基づくことで、拡張性と柔軟性に富んだウェブスケールのアーキテクチャを構築することができます。
REST APIのURLの設計と命名規則
上記のREST APIの設計原則から、REST APIはすべてのリソースに対して一意のURLを割り当てるべきだという原則があります。例えば、あるユーザーのプロフィールリソースのURLは「https://example.com/api/users/12345」のように指定します。リソースは可能な限り具体的な名詞を使用してURLで表現することが望ましいです。URLでは動詞の使用は禁止されています。具体的にどのような操作を指定するには、HTTPメソッドなどのGET（データ取得）、POST（データ追加）、PUT（データ更新）、DELETE（データ削除）と一緒に使ってデータのCRUD操作を行う必要があります。
REST API URLの命名規則
上記の設計原則に基づいて、直感的で分かりやすい構造のURLを設計し、HTTPメソッドで均一な操作を実現することがREST APIの設計において重要です。ここで、より詳しいREST APIのURL命名規則を紹介します。
- リソースを表す名詞を使用する 例:/users, /articles
- 名詞の複数形や単数形を整合的に使用する 例:/users, /user
- ネストする場合はスラッシュ区切りを使用する 例:/users/12345/articles
- ハイフンは読みやすさのために使用する 例:/articles/programming-tips
- アクションを示す動詞は使用しない 例:✖ /getUsers ○ /users
- 大文字は避け、小文字を使用する
- ファイル拡張子は含めない
- バージョン番号を含める. 例:/v1/users
- 長過ぎなく意味のある名前を選択する
このような自然なルールに従うことで、開発者にとって理解しやすく、処理しやすいREST APIのURL設計が可能になります。
ApidogでREST APIを迅速に設計・開発
REST APIに詳しい方は、APIの設計は様々な方面に及ぼすことがあることがわかっていると思います。データ構造の構築、エラー処理、API仕様書の作成と修正などの仕事の中で、チーム全体がAPI仕様書を巡って作業を進めることがよく見られます。それに伴い、チームが使用しているツールはますます多くなっています。例えば、Swaggerを使ってAPI仕様書を作成したり、Postmanを使ってAPIをデバッグしたり、JMeterを使ってAPIをテストしたりするようになります。もし作業にAPIのデータモックを必要とする場合、またモックサーバーを使ってFaker.jsを作成する必要があります。このようなプロセスが複雑すぎませんか？
そこで、より便利にAPIに関わる作業を扱えるツールを皆さんに紹介していきたいと思います。それはApidogです。ApidogはAPI開発のライフサイクルで利用可能な包括なプラットフォームです。以前複数のツールを使って開発するAPIは、これからApidogという単一のプラットフォームで全部実現可能になりました。Apidogというソフトは、Postman、Swagger、JMeter、Mockの全機能を集成しています。API開発に関するすべての仕事は、Apidogによって実現されるので、API開発の効率性がかなり向上させ、開発者の時間をも大幅に節約できます。それでは、今すぐこのソフトをダウンロードして、その素晴らしい機能を試してみましょう。
まとめ
この記事では、REST API設計の原則である「アドレス可能性」に基づき、リソースに対して一意のURLを割り当てることの重要性を説明しました。リソースを表す具体的な名詞をURLに用い、動詞は使用しないことなど、REST APIにおけるURLの設計原則と命名規則のベストプラクティスを示しました。
また、自然なルールに従うことで分かりやすく処理しやすいURL設計が実現できること、Apidogといったツールを使えばAPI開発プロセスを効率化できるので、ぜひ活用してみましょう。
