REST APIとは

まず、2000年にコンピューター科学者のRoy Fielding博士が博士論文で定義したRESTは、開発者に比較的高いレベルの柔軟性、拡張性、効率性をもたらします。そのような理由から、REST APIは、マイクロサービス・アーキテクチャーでコンポーネントとアプリケーションを接続するための一般的な方法として登場しました。

最も基本的なレベルのAPIは、アプリケーションまたはサービスが別のアプリケーションまたはサービス内のリソースにアクセスできるようにするメカニズムです。リソースにアクセスするアプリケーションやサービスがクライアントで、リソースを含むアプリケーションやサービスがサーバーです。 SOAPやXML-RPCなどの一部のAPIは、開発者に厳格なフレームワークを課します。しかし、開発者は事実上あらゆるプログラミング言語を使用してREST APIを開発でき、さまざまなデータ形式をサポートできます。唯一の要件は、次の6つのREST設計原則（アーキテクチャー上の制約ともいいます）に準拠することです。

同じリソースへのAPI要求はすべて、要求の送信元に関係なく、同じに見える必要があります。REST APIでは、ユーザーの名前やメールアドレスなど、同じデータが1つのUniform Resource Identifier（URI）にのみ属するようにする必要があります。リソースは大きすぎてはいけませんが、クライアントが必要とする可能性のあるすべての情報を含めなければなりません。

REST API設計では、クライアント・アプリケーションとサーバー・アプリケーションは互いに完全に独立している必要があります。 クライアント・アプリケーションが認識する必要がある唯一の情報は、要求されたリソースのURIです。他の方法でサーバー・アプリケーションと対話することはできません。 同様に、サーバー・アプリケーションは、HTTP経由で要求されたデータに渡す以外に、クライアント・アプリケーションを変更してはなりません。

REST APIはステートレスなので、それぞれの要求には、その処理に必要なすべての情報が含まれていなければなりません。ということはつまり、REST APIはサーバー側のセッションを必要としません。 サーバー・アプリケーションは、クライアントの要求に関連するデータを保存することはできません。

可能な場合、リソースはクライアント側またはサーバー側でキャッシュ可能である必要があります。 サーバーの応答には、送信されたリソースのキャッシュが許可されているかどうかに関する情報も含まれる必要があります。 その目標は、サーバー側のスケーラビリティを向上させながら、クライアント側のパフォーマンスを向上させることです。

REST APIでは、呼び出しと応答はさまざまなレイヤーを通過します。 経験則として、クライアント・アプリケーションとサーバー・アプリケーションが相互に直接接続することを前提としないでください。 通信ループには多数の異なる仲介者が存在する可能性があります。 REST API は、クライアントもサーバーも、エンド・アプリケーションと通信するのか仲介者と通信するのかを判断できないように設計する必要があります。

REST API は通常、静的リソースを送信しますが、場合によっては、応答に実行可能コード（Javaアプレットなど）が含まれることもあります。 そのような場合、コードはオンデマンドでのみ実行される必要があります。

REST APIはHTTP要求を介して通信し、リソース内のレコード（別名：CRUD）の作成、読み取り、更新、削除などの標準的なデータベース関数を実行します。

たとえば、REST APIはGET要求を使ってレコードを取得します。 POST要求は、新しいレコードを作成します。 PUT要求はレコードを更新し、DELETE要求はレコードを削除します。 API呼び出しではすべてのHTTPメソッドを使用できます。 適切に設計されたREST APIは、HTTP機能が組み込まれたWebブラウザーで実行されるWebサイトに似ています。

特定の瞬間またはタイムスタンプにおけるリソースの状態は、リソース表現といいます。 この情報は、JavaScript Object Notation（JSON）、HTML、XLT、Python、PHP、プレーン・テキストなど、実質的にあらゆる形式でクライアントに送信できます。 JSONが人気があるのは、人間とマシンの両方が読み取り可能であり、プログラミング言語に依存しないためです。

要求ヘッダーとパラメーターには、メタデータ、承認、Uniform Resource Identifier（URI）、キャッシュ、Cookieなどの重要な識別子情報が含まれているため、REST API呼び出しでも重要です。 要求ヘッダーと応答ヘッダーは、従来のHTTP状態コードと共に、適切に設計されたREST API内で使用されます。

柔軟性はREST API設計の大きな利点ですが、その柔軟性により、壊れたAPIやパフォーマンスの低いAPIも簡単に設計できてしまいます。 そのため、プロの開発者はREST API仕様のベスト・プラクティスを共有しています。

OpenAPI仕様（OAS）は、開発者やアプリケーションがAPIを発見し、そのパラメーターと機能を完全に理解できる方法でAPIを記述するためのインターフェースを確立します。この情報には、利用可能なエンドポイント、各エンドポイントで許可された操作、操作パラメーター、認証方法などが含まれます。最新バージョンのOAS3には、さまざまなプログラミング言語でAPIクライアントとサーバー・スタブを生成するためのOpenAPI Generatorなどの実践的なツールが含まれています。

REST APIのセキュリティー保護も、業界のベスト・プラクティスから始まります。パスワードのセキュリティーにはハッシュ・アルゴリズムを使用し、安全なデータ送信にはHTTPSを使用します。OAuth 2.0のような認証フレームワークは、サードパーティ・アプリケーションの権限を制限するのに役立ちます。

APIは、HTTPヘッダーのタイムスタンプを使用して、一定期間後に到着した要求を拒否することもできます。パラメーター検証とJSON Webトークンは、承認されたクライアントのみがAPIにアクセスできるようにするもう1つの方法です。