card-Components-of-an-API

API は、ソフトウェア コンポーネントがデータを通信および転送できるようにするコードベースの命令のセットであり、最新のすべてのアプリケーションの構成要素です。しかし、API 自体の構成要素は何でしょうか?この記事では、リクエストをエンドツーエンドでたどることによって、REST API のさまざまなコンポーネントを確認します。

API リクエストは、さまざまな方法でトリガーできます。たとえば、ユーザーは、検索用語を入力するか、ボタンをクリックするか、Web またはモバイル アプリケーションのリストをスクロールすることによって、API 要求を開始する場合があります。 API リクエストは、別のアプリケーションやサービスからの通知など、外部イベントに応答して発行される場合もあります。 API リクエストがどのようにトリガーされても、API クライアントはそれを組み立てて API サーバーに送信する責任があります。

「API クライアント」というフレーズは、文脈によって意味が異なることに注意してください。まず、API リクエストを手動で送信する際の複雑さの一部を抽象化する開発ツールを参照できます。これにより、API の調査、テスト、およびデバッグが容易になります。また、言語固有のライブラリと SDK を使用して、より大きなアプリケーションのコンテキストで API 要求を開始するサービスを指すこともあります。どちらのタイプの API クライアントも、API によって返されたデータを処理し、それをユーザーに提示する責任がありますが、後者のタイプのクライアントは、返されたデータをアプリケーションの論理フローで使用することもできます。

API クライアントは、ユーザー アクションまたは外部イベントに応答して API リクエストを送信する役割を担うと説明しましたが、API リクエストとは正確には何なのでしょうか? API リクエストは、API のタイプによって外観と動作が異なります。つまり、REST API への API リクエストは次のコンポーネントで構成されています。

• 終点： すべての API リクエストは、特定のリソースへのアクセスを提供する専用 URL である API エンドポイントに送信されます。たとえば、e コマース アプリの /products エンドポイントには、製品に関連するすべての要求を処理するためのロジックが含まれます。したがって、リクエストはエンドポイントを指定して、API サーバーが処理方法を認識できるようにする必要があります。 API サーバーについては、後ほど詳しく説明します。
• 方法: すべての API リクエストには、指定されたリソースに対してクライアントが実行したい操作を定義するメソッドが含まれている必要があります。 REST API は、GET、POST、PUT、PATCH、DELETE などの標準 HTTP メソッドを介してアクセスでき、データの取得、作成、更新、または削除などの一般的なアクションを容易にします。 /products エンドポイントへの GET 要求は、データベース内のすべての製品を返すように API サーバーに指示します。
• パラメーター: パラメータは、API が処理する特定の指示を提供するために API エンドポイントに渡される変数です。これらのパラメータは、URL の一部として API リクエストに含めるか、クエリ文字列、またはリクエスト本文に含めることができます。たとえば、e コマース API の /products エンドポイントは、特定の色の製品にアクセスして返すために使用する「color」パラメーターを受け入れる場合があります。
• リクエストヘッダー: API リクエスト ヘッダーは、リクエストに関する追加情報を提供するキーと値のペアです。たとえば、Content-Type ヘッダーは要求本文のデータの形式を指定し、Authorization ヘッダーは API キーや OAuth トークンなどの認証資格情報を提供して要求者を認証します。
• リクエスト本文: 要求本文には、リソースの作成、更新、または削除に必要な実際のデータが含まれます。たとえば、e コマース ストアの管理者が新しい製品を作成する必要がある場合、要求の本文には製品の名前、ブランド、および価格が含まれる場合があります。 API 仕様では、JSON や XML など、要求に必要なデータ形式が規定されています。

API クライアントが要求を組み立てると、処理のために API サーバー上の適切なエンドポイントに送信します。 API サーバーは、認証の処理、入力データの検証、データベースからのデータの取得または操作、およびクライアントへの適切な応答の返しを担当します。

データベース自体は API コンポーネントではありませんが、API はデータベースなしでは機能しないことに注意してください。 API サーバーが要求に基づいてアプリケーション データを取得および操作するのに対し、データベースは効率的な取得と操作を容易にする方法でこのデータを格納および編成します。したがって、API サーバーは、API クライアントとデータベースの間の仲介者として機能します。

APIサーバーは、リクエストを処理した後、クライアントにレスポンスを送信する責任があると前述しました。 API 応答の内容は、要求のタイプと API の設計によって大きく異なりますが、通常は次のコンポーネントが含まれます。

• ステータス コード: API ステータス コードは、クライアントのリクエストのステータスを示すために API によって返される HTTP ステータス コードです。これらのコードは、リクエストの結果に関する情報をクライアントに提供し、クライアントが処理方法を理解できるようにするために使用されます。最も一般的なステータス コードには、サーバーが要求されたデータを正常に返したことを示す 200 OK、サーバーが新しいリソースを正常に作成したことを示す 201 Created、サーバーが要求されたデータを見つけることができなかったことを示す 404 Not Found などがあります。リソース。
• 応答ヘッダー: 応答ヘッダーは、サーバーの応答に関する追加情報を提供するために使用されることを除いて、要求ヘッダーと非常によく似ています。たとえば、Cache-Control ヘッダーはデータをキャッシュに保存できる期間の指示を提供し、Set-Cookie ヘッダーはセッション管理または認証に使用できる Cookie をブラウザーに設定します。
• レスポンス本文: 応答本文には、クライアントの要求に応じて API サーバーから返されるデータまたはコンテンツが含まれます。応答本文はさまざまですが、通常、要求されたリソース、メタデータ、および (要求が失敗した場合は) 問題に関するエラー メッセージを表す構造化データ オブジェクトが含まれます。たとえば、特定の製品に対する成功した GET 要求には、その製品の JSON 表現、タイムスタンプ、およびデータのソースが含まれる場合があります。

REST は最も一般的な API アーキテクチャですが、GraphQL や gRPC などの他のタイプの API には異なるコンポーネントがあります。それにもかかわらず、このリストには、すべての RESTful API へのリクエストの実行に関与するコア コンポーネントが含まれています。

現在、何万人もの開発者が Apitgit プラットフォームを使用しています。 Apitgit は API ライフサイクルの各ステップを簡素化し、コラボレーションを合理化するため、より優れた API をより速く作成できます。