REST API とそのアーキテクチャ

PHPz
リリース: 2024-09-08 20:33:07
オリジナル
657 人が閲覧しました

はじめに

今日の Web 開発の世界では、API (アプリケーション プログラミング インターフェイス) が、異なるソフトウェア システム間の通信を可能にする上で重要な役割を果たしています。最も広く使用されているタイプの API の 1 つは、Representational State Transfer の略である REST API です。 REST API は、スケーラブルで保守性が高く、効率的な Web サービスを構築するための標準になっています。このブログでは、REST API とは何か、その原理、アーキテクチャ、コンポーネント、およびそれらを効果的に設計および実装する方法について詳しく説明します。

REST API とは何ですか?
REST (Representational State Transfer) は、ネットワーク化されたアプリケーションを設計するためのアーキテクチャ スタイルです。これはステートレスなクライアント/サーバー通信モデルに依存しており、標準の HTTP メソッドに基づいています。 REST API を使用すると、さまざまなアプリケーションが、単純な規則セット、つまりルールを使用してインターネット上で通信できるようになります。

REST API and Its Architecture

REST API は、HTTP リクエストを送信し、HTTP レスポンスを受信することによって、クライアント (ブラウザや携帯電話などの Web またはモバイル アプリケーション) がサーバーと対話できるようにするインターフェイスです。サーバーは、ユーザー プロフィールから画像やブログ投稿まで、あらゆるリソースへのアクセスを提供します。
REST の重要な原則
RESTful であるとみなされるには、API に次の 6 つの原則が必要です:

  1. クライアントサーバーアーキテクチャ: クライアントとサーバーは互いに独立している必要があります。クライアントはユーザー インターフェイスとユーザー エクスペリエンスを担当し、サーバーはバックエンド ロジック、データ ストレージ、および処理を処理します。
  2. ステートレス性: クライアントからサーバーへの各リクエストには、リクエストを理解して処理するために必要なすべての情報が含まれている必要があります。サーバーはリクエスト間のクライアント情報を保存しません。これにより、サーバーの設計が容易になり、拡張性が向上します。
  3. キャッシュ可能性: サーバーからの応答はキャッシュ可能かキャッシュ不可能かを明確に定義する必要があります。応答がキャッシュ可能であれば、クライアントは今後のリクエストで応答データを再利用できるため、サーバーの負荷が軽減され、パフォーマンスが向上します。
  4. 統一インターフェイス: REST API は、リソースと対話するための一貫した標準化された方法を提供する必要があります。これは 4 つの副原則によって達成されます。  - リソースの識別: リソースは URI (Uniform Resource Identifier) を使用して識別されます。  - 表現によるリソースの操作: クライアントは、リクエストで表現 (JSON、XML など) を送信することでリソースと対話します。  - 自己記述的なメッセージ: 各リクエストと応答には、メッセージの処理方法を説明するのに十分な情報が含まれている必要があります。  - アプリケーション状態のエンジンとしてのハイパーメディア (HATEOAS): クライアントは、応答で提供されるハイパーリンクを使用して API を動的に移動する必要があります。
  5. 階層化システム: アーキテクチャでは、クライアントがこれらの層を意識することなく、クライアントとサーバーの間でキャッシュ層、負荷分散層、セキュリティ層などの中間層を使用できる必要があります。
  6. コード オン デマンド (オプション): サーバーは、クライアント側で実行される JavaScript などの実行可能コードを送信することで、クライアントの機能を拡張できます。これは REST のオプションの制約です。

REST API アーキテクチャ
REST API のアーキテクチャは、クライアントとサーバー間の通信を確立するために連携して機能するいくつかの主要なコンポーネントで構成されています。

  1. リソース: リソースは REST API の中核概念です。これらは、ユーザー、製品、注文など、API がアクセスを提供するデータまたはオブジェクトを表します。各リソースは一意の URI によって識別されます。

  2. HTTP メソッド: REST API は標準の HTTP メソッドを使用して、リソースに対して CRUD (作成、読み取り、更新、削除) 操作を実行します。
     - GET: リソースからデータを取得します。
     - POST: リソース(DB)に新しいデータ変更を作成します。
     - PUT: データ(DB)内の既存のレコードを更新します。
     - DELETE: DB から特定のデータを削除します。
     - PATCH: 既存のデータを部分的に更新します。
     - オプション: リソースに対してサポートされている HTTP メソッドを取得します。

  3. HTTP ステータス コード: REST API は、標準の HTTP ステータス コードを使用してリクエストの結果を示します。一般的なステータス コードは次のとおりです:
     - 200 OK: リクエストは成功しました。
     - 201 作成: 新しいリソースが正常に作成されました。
     - 204 コンテンツなし: リクエストは成功しましたが、返されるコンテンツがありません。
     - 400 Bad Request: リクエストの形式が間違っているか、無効です。
     - 401 Unauthorized: クライアントはリソースにアクセスするには認証する必要があります。
     - 404 見つかりません: 要求されたリソースが見つかりませんでした。
     - 500 内部サーバー エラー: サーバーで予期しないエラーが発生しました。

  4. 表現形式: REST API は、JSON (JavaScript Object Notation)、XML (eXtensible Markup Language)、HTML など、データ交換のためのさまざまな表現形式をサポートしています。 JSON は、そのシンプルさと JavaScript との互換性により、最も一般的に使用される形式です。

  5. エンドポイント: エンドポイントは、サーバーから特定のリソースにアクセスできる場所を定義する URL です。各エンドポイントは特定のリソースに対応し、通常は動詞ではなく名詞を使用して設計されます (/users、/products など)。

RESTful API の設計

RESTful API の設計には、REST 原則に準拠し、クライアントにシームレスなエクスペリエンスを提供するためのいくつかの手順が含まれます。 REST API を設計するためのベスト プラクティスをいくつか示します:

  1. エンドポイントに名詞を使用する: エンドポイントの名前は、アクション (動詞) ではなくリソース (名詞) にちなんで付ける必要があります。たとえば、ユーザーのコレクションを表すには、/getUsers ではなく /users を使用します。

  2. HTTP メソッドを適切に使用する: 各操作に正しい HTTP メソッドを使用します。たとえば、データを取得するには GET を使用し、データを作成するには POST を使用し、データを更新するには PUT を使用し、データを削除するには DELETE を使用します。

  3. フィルタリング、並べ替え、ページネーションの実装: リソースのリストを返すエンドポイントの場合、フィルタリング、並べ替え、ページネーションを実装して、パフォーマンスを向上させ、クライアントへの制御を強化します。これを実現するには、?sort=name、?page=2、?limit=10 などのクエリ パラメータを使用します。

  4. API のバージョンを設定する: 既存のクライアントを壊すことなく変更を処理できるように、API のバージョンを常に設定してください。 URL (例: /api/v1/users) またはヘッダーにバージョン番号を含めます。

  5. 意味のある HTTP ステータス コードを提供する: リクエストの結果を示す適切な HTTP ステータス コードを返します。すべての応答に 200 OK を使用することは避けてください。

  6. ハイパーメディア (HATEOAS) を使用する: 応答にリンクを含めて、クライアントが URL をハードコーディングせずに API を動的に移動できるようにします。

  7. セキュリティの確保: HTTPS を使用して API を保護し、転送中のデータを暗号化します。リソースへのアクセスを制御するための認証 (OAuth、JWT など) と認可を実装します。

  8. エラーを適切に処理する: 意味のあるエラー メッセージと HTTP ステータス コードを提供して、クライアントが何が問題なのかを理解できるようにします。エラー コード、メッセージ、考えられる解決策などの詳細を含む再利用可能なエラー形式を作成します。

REST API 設計の例

書籍のコレクションを管理するための単純な REST API の例を考えてみましょう:

  1. エンドポイント: /api/v1/books
  2. GET /api/v1/books: db からすべての書籍のリストを取得します。  - POST /api/v1/books: db に新しいブックを作成します。
  3. エンドポイント: /api/v1/books/{id}
  4. GET /api/v1/books/{id}: ID によって特定の書籍を返します。  - PUT /api/v1/books/{id}: ID によって特定の書籍を更新します。  - DELETE /api/v1/books/{id}: ID に基づいて特定の書籍を削除します。
  5. エラー処理の例:
  6. クライアントが存在しない書籍をリクエストした場合:   - 応答: 404 見つかりません   - ボディ: ボディは次のようになります

REST API and Its Architecture

REST API の実装

REST API を実装するには、さまざまなプログラミング言語とフレームワークを使用できます。 Node.js と Express.js を使用する例を次に示します。

REST API and Its Architecture

以上がREST API とそのアーキテクチャの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。

ソース:dev.to
このウェブサイトの声明
この記事の内容はネチズンが自主的に寄稿したものであり、著作権は原著者に帰属します。このサイトは、それに相当する法的責任を負いません。盗作または侵害の疑いのあるコンテンツを見つけた場合は、admin@php.cn までご連絡ください。
著者別の最新記事
人気のチュートリアル
詳細>
最新のダウンロード
詳細>
ウェブエフェクト
公式サイト
サイト素材
フロントエンドテンプレート
私たちについて 免責事項 Sitemap
PHP中国語ウェブサイト:福祉オンライン PHP トレーニング,PHP 学習者の迅速な成長を支援します!