REST API（RESTful APIまたはRESTful Web API）とはRepresentational State Transfer（REST）アーキテクチャー方式の設計原則に従ったアプリケーション・プログラミング・インターフェース（API）のことです。REST APIは、アプリケーションを統合し、マイクロサービス・アーキテクチャー内のコンポーネントを接続するための柔軟で軽量な方法です。
コンピューター科学者のRoy Fielding博士は2000年に発行した博士論文の中で、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）の作成、読み取り、更新、削除などの標準的なデータベース関数を実行します。
例えば、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つの方法です。
一貫性のある直感的なエクスペリエンス、受賞歴のある設計ツール、組み込み型のAI機能を使って、ライフサイクル全体のAPIを作成、管理、保護、共有、収益化できます。
アプリケーションの連携、データ統合、B2B統合、プロセス自動化のための柔軟なツールを使って、すべてのアプリケーションとデータに接続性を提供します。
アプリケーションとシステムを迅速かつ安全に接続して、重要なデータをロック解除し、プロセスを自動化し、ビジネスの可能性を解き放ちます。
アプリケーション・プログラミング・インターフェース（API）を使ってアプリケーション間でデータと機能を簡単、安全に交換できるようにすることで、ソフトウェア開発とイノベーションを簡素化する方法をご紹介します。
API管理、また統合API管理プラットフォームが組織の規模拡大にどのように役立つかをご紹介します。
Gartner社がIBMをリーダーに選出した理由の詳細については、2023年度 Gartner® Critical Capabilities for Full Lifecycle API Managementレポートをお読みください。