コンセプトのレビュー: API と API 相互接続

原作者:NGINX

元のリンク:コンセプトレビュー: API と API 相互接続

転載元:NGINXオープンソースコミュニティ


NGINX の唯一の公式中国語コミュニティ (すべてnginx.org.cn )

マイクロサービス アーキテクチャの台頭により、API の数が劇的に増加し、それによって一連の課題と解決策も生まれています。この記事を読んで、API に関連する基本概念と API の使用状況について学びましょう。

アプリケーション プログラミング インターフェイス (API) とは何ですか?

アプリケーション プログラミング インターフェイス (API) は、ユーザー (人またはソフトウェア) と情報 (オンラインおよび Web アプリケーションによって提供されるデータ リソース) という 2 つのエンティティ間の通信をサポートする一連の定義、ルール、およびプロトコルです。

現在、API は最新のアプリケーションの基本フレームワークを形成し、ユーザー エクスペリエンスの向上とビジネス モデルの強化に役立ちます。場合によっては、API がそれ自体でビジネス モデルとして機能することもあります。

APIはどのように機能するのでしょうか?

API はアプリケーションの「顔」であり、アプリケーションが実行する機能と提供できる情報を示し、正しい要求形式を定義します。開発者がアプリケーションの API を作成して公開すると、他のアプリケーションがそのアプリケーションと通信できるようになります。

多くの場合、API を使用すると、よく使用される機能がすぐに利用できるようになるため、開発者は貴重な時間を節約できます。開発者は、関数の再開発に時間を浪費することなく、既存のアプリケーションの API を呼び出すことで、必要な関数を独自のアプリケーションに統合できます。

各 API の設計、デプロイ、および操作の方法は、そのアーキテクチャ スタイルまたはプロトコルによって異なります。

API アーキテクチャとプロトコルの種類 

API アーキテクチャまたはアーキテクチャ スタイルは、API の構造と構成、およびその要求/応答形式を含む、API のトップレベルの設計を指します。API プロトコルは形式を指定するだけでなく、正確なメッセージも記述します。

一般的な API アーキテクチャとプロトコルには次のものがあります。

  • REST – RESTful とも呼ばれるこのアーキテクチャ スタイルは、状態転送を特徴付ける原則に基づいています。HTTP メソッド (GET、POST、PUT、DELETE など) と抽象情報 (リソースおよびリソース モデルの形式) を使用して、拡張可能で柔軟なテクノロジに依存しない構造を作成します。現在でも、REST は最も人気のある API アーキテクチャです。

  • GraphQL - Meta (以前は Facebook) によって開発されたオープン ソース クエリ言語。GraphQL アーキテクチャは、単一の API 呼び出しで複数のソースからデータを取得することをサポートします。クライアントは必要なデータのみを要求するため、GraphQL API は REST API よりも効率的である (ただしキャッシュ可能性は低い) 傾向があります。

  • SOAP  このアーキテクチャ アプローチでは、Simple Object Access Protocol  (SOAP) を使用します。通常、SOAP メッセージは XML 形式であるため、REST や GraphQL よりも少し扱いに​​くくなります。REST API とは異なり、SOAP API は厳密な実装ガイドラインを使用して API プロトコルの構造を定義します。

  • WebSocket - この API プロトコルは全二重通信プロトコルであり、クライアントとサーバーが同時にメッセージを送受信できることを意味します。さらに、サーバーによって送信されるメッセージはクライアントの要求に応答するものではなく、(たとえば) サーバー側のイベントによってトリガーされる場合があります。対照的に、REST API は厳密な要求と応答のパターンに従います。

  • RPC -リモート プロシージャ コールを使用すると、開発者は、リモート インタラクションの詳細を指定することなく、ローカル関数を呼び出すのと同じように、同じコードを使用して、異なるアドレス空間 (通常はリモート サーバー上) で実行されている関数を呼び出すことができます。このプロトコルは多くの言語で使用できるため柔軟性があり、クライアントとサーバーの通信によく使用されます。gRPC (Google Remote Procedure Call) は RPC の一種です。

API利用状況 

API は最新のソフトウェアの重要なコンポーネントであり、今日の企業はニーズに応じてさまざまな種類の API を構築または使用しています。

現在、企業で最も一般的な 4 つの API は、パブリック API、プライベート API、パートナー API、およびサードパーティ APIです。

パブリックAPI 

パブリック API は企業外のユーザー (有料または無料) にアクセスできるため、サードパーティの開発者と提携してビジネス エコシステム全体を拡張できます。

パブリック API はサードパーティの開発者が新しい製品を構築するために使用できるため、イノベーションの推進に役立ち、新しいパートナーシップの構築に役立つ重要なツールです。

プライベートAPI 

組織内のチームのみがアクセスできるプライベート API は、データのロックを解除して内部コラボレーションを促進するだけでなく、Web サイトなどの公開アプリケーションに目に見えないサポートも提供します。

プライベート API は内部ユーザーのみが利用できるため、企業は最適化を念頭に置いて API を構築できます。また、プライベート API により最新のアプリケーションの構成可能性が向上し、企業が現在のニーズに適応できるようになります。開発者はマイクロサービスを構築するときにプライベート API を簡単に統合できるため、チーム間での作業の重複が軽減されます。

パートナーAPI

パートナー API は、ビジネス パートナー ソリューションを直接統合するために使用されます (たとえば、航空会社がホテル チェーンと提携している場合、航空券とホテルを一緒に予約できます)。Partner API は一般公開されていません。両方の企業の認証 (AuthN) と認可 (AuthZ) の要件を満たす、選ばれた開発者グループのみがアクセスできます。

相互運用性によりパートナー API との関係が強化されます。これは、サイロを解消し、さまざまな企業が相互に通信できるようにするためです。

サードパーティAPI 

企業はサードパーティ API を使用して、アプリやサービスに欠けているデータや機能にアクセスできます。これらの API はサードパーティのサーバー上で実行され、多くの場合、広く必要とされるサービス (多くの電子商取引サイトで使用される Stripe 支払い処理 API など) を提供します。これらの API は、API に応じて有料または無料で企業が使用できます。

サードパーティ API は他の開発者や企業によって構築されているため、大幅なコスト削減を実現できます。さらに、サードパーティ API は、開発者が自分で作成しなくても必要な機能をすぐに使用できるため、企業がアプリケーション開発をスピードアップするための重要な方法です。

API の作成にはどのアプリケーション言語が使用されますか?

ほとんどすべての最新のプログラミング言語を使用して API をコーディングできます。API をコーディングするとき、多くの開発者はフレームワークの使用を選択する場合があります。フレームワークは、コード ライブラリやその他の必要なユーティリティなどの構築ブロックを提供し、言語を使用したアプリケーションの構築をより迅速かつ簡単にします。

通常、各プログラミング言語には、開発者がよく使用する 1 つ以上のフレームワークがあります。以下の表に、いくつかのフレームワーク オプションを示します (その多くはオープン ソースです)。

言語とフレームワークの正確な選択は、多くの場合、プロジェクトのニーズや開発者の個人的な好みによって決まります。

APIの例

API は現代のソフトウェア開発の基本的な部分であり、API の例は無数にあります。ここでは、ほんの数例を示します。

3 つの API の例:

  • Google Maps Platform - Google が提供する API で、Google マップを Web サイトまたはアプリケーションに埋め込むことができます。

  • AWS IoT - AWS IoT API を使用すると、モノのインターネット上のデバイス (スマート ホーム デバイスなど) を AWS クラウドに接続できます。これは、スマート ホーム オートメーション システムを構築する 1 つの方法です。

  • NGINX Unit Control API - Unit API は REST アーキテクチャを使用して、オープンソース NGINX Unit アプリケーションと Web サーバーを構成します。

API ポリシーとは何ですか? 

企業は、ビジネス目標に基づいて最新の API 戦略を開発する必要があります。これは、企業が API をどのように設計、開発、管理、管理、保護するかを定めたものです。

Gartner の「ソフトウェア エンジニアリング リーダーのための 5 つの API レッスン」によると、強力な API 戦略を確実に実装するために役立つ 5 つのベスト プラクティスが存在します。

  • API ガバナンスによってボトルネックが発生しないようにしてくださいイノベーションを継続的に推進するには、API ガバナンスと開発者の機敏性のバランスを取る必要があります。

  • API から収益を上げる予定がない場合でも、API を製品と考えてください。各 API には、ビジネス目標に合致する明確な目的と対象者があることを確認してください。

  • ハッカーが発見する前に API を発見しましょう。発見可能性と定期的な監視に重点を置くことで、セキュリティ侵害を防ぐことができます。

  • API のライフサイクルを管理します。包括的な API ライフサイクル管理により、API が適切なセキュリティ保護のもとで動作し続けることが保証されます。

  • 最も適切な API テクノロジーを選択してください。他のビジネスで機能するテクノロジーが、あなたにとっては機能しない可能性があるため、現在および将来の特定の API ニーズを詳細に検討する必要があります。

どのタイプの API アーキテクチャを選択するか、どのタイプの API を作成するかに関係なく、API のセキュリティは事後的に作り上げるのではなく、最初から考慮する必要があります。

API相互接続とは何ですか? 

「API 相互接続」とは、クラウドネイティブ環境でデータとアプリケーションを接続するためのモジュール式の再利用可能な API の使用を指します。個々の API のライフサイクルの管理に重点を置く API 管理とは異なり、API 相互接続には疎結合されたマイクロサービス環境 (多くの API が相互に通信する環境) が含まれ、これらのアーキテクチャで大規模な API の保護とガバナンスが可能になります。

API はかつては開発者のための単なるツールとみなされていましたが、収益を生み出すだけでなく企業の機敏性もサポートする戦略的なビジネス資産となっています。企業が API の革新と導入を続けるにつれて、視覚化、セキュリティ保護、ガバナンスに関して新たな課題が生じています。企業は、従来のマイクロサービス アーキテクチャを補完し、DevOps の実践に適合し、高性能 API をサポートする、新しい API 相互接続ソリューションを必要としています。

API タイプと API 接続エクスペリエンス 

これまで、フル ライフサイクル API 管理ソリューションは主に、内部または外部 API の North-South トラフィック (クライアントからバックエンドへ) を管理するために使用されていました。現在、クラウド ネイティブ インフラストラクチャがより多くの東西トラフィック (エンタープライズ アプリケーション インフラストラクチャ内のマイクロサービス間) を生成し続けるにつれて、API の種類が増加しています。

現在、ほとんどの企業は次の 4 種類の API を使用しています。

  • 内部 API  - 企業内の他のアプリケーション (およびその開発者) にのみ公開され、外部ユーザーには公開されません。内部 API は、データのロックを解除し、企業内の機能間のコラボレーションを促進するのに役立ちます。

  • 外部 API  – 企業外のユーザーに公開されます。外部 API により、サードパーティ開発者やビジネス エコシステム全体とのパートナーシップが可能になり、収益源となる可能性があります。

  • パートナー API — ビジネス パートナーに公開されます。これらの API は公開されていません。両方の企業の認証 (AuthN) と認可 (AuthZ) の要件を満たす、選ばれた開発者グループのみがアクセスできます。

  • サードパーティ API  — サードパーティによって公開され、そのサーバー上でホストされます。これらの API は、広く必要とされるサービス (地図など) を提供するためによく使用され、他社が使用するために特別に開発されており、通常は有料です。

API 相互接続のその他の重要な要素には、API ゲートウェイ (リバース プロキシまたはイングレス コントローラー) と API 開発者ポータルが含まれます。API ゲートウェイは、クライアントからの API リクエストを受け入れ、対応するサービスに転送し、リクエストの結果をユーザーの同期エクスペリエンスに統合します。開発者ポータルは、外部 API のカタログ、包括的なドキュメント、サンプル コードなど、API 利用者がすぐに使い始めるのに役立つリソースを公開できるオンライン プラットフォームです。また、サードパーティの開発者がアプリケーションを登録し、API アクセス資格情報を取得できるようになります。

マルチクラウドの課題

現在、API とマイクロサービスは両方とも、パブリック クラウド、プライベート クラウド、オンプレミス、エッジなどの複数の環境にデプロイされることになります。トラフィックの多い企業がアプリケーションを拡張するための重要なツールとしてマイクロサービスがますます重要になる につれ、内部 API トラフィックも大幅に増加しています。

複雑なマルチクラウド環境で API エンドポイントが急増するには、API 管理、ガバナンス、セキュリティに対する新しいアプローチが必要です。これらの分散環境では、開発者に権限を与え、プラットフォーム運用チームがさまざまな事業分野にわたってセキュリティとリソース保護を設定できるようにする、ロータッチの自動化されたアプローチが必要です。

マルチクラウド アーキテクチャの信頼性とセキュリティを確保することは、プラットフォームの運用および保守チームにとって深刻な課題となります。アプリケーションと API トラフィックを完全に可視化し、さまざまな環境に一貫したセキュリティ ポリシーとコンプライアンス ポリシーを適用できる機能が必要です。プラットフォーム ネイティブ ツールは動作方法が異なり、さまざまな程度の可視性と制御を提供します。最終的に、プラットフォーム運用チームは他のモデルを使用して、分散したチームや環境全体にガバナンス ルールを作成して適用する必要があります。

API ガバナンスには、集中型と分散型の 2 つの一般的なモデルがあります。しかし、最新の API 戦略、特に API ファースト モデルでは、「適応型ガバナンス」という新しい概念が API 開発者に力を与えると同時に、プラットフォームの運用および保守チームに信頼性とセキュリティ保護の制御機能を提供します。

詳細については、ブログ投稿「アダプティブ ガバナンスにより API 開発者に必要な自律性が与えられます」を参照してください。

API ファースト ツールの重要性

クラウドネイティブ環境は、通常、コンテナー、サービス メッシュ、マイクロサービスを使用して構築される疎結合システムです。上記のリソースは API を介して相互に通信し、多くの場合、宣言型 API を介して自律的に管理されます。これらの技術により、耐障害性があり、管理が容易で、観察が容易なシステムを構築できます。

API 相互接続では、クラウドネイティブ テクノロジの使用、特にインフラストラクチャと API ライフサイクルを管理するための API ファーストのアプローチが強調されます。これは、継続的インテグレーション/継続的デリバリー (CI/CD) プラクティスを使用して大規模な運用を自動化する場合に特に重要です。CI/CD は、自動化機能を通じてライフサイクル全体 (オーサリング、配信、更新) を通じて API とアプリケーションを効率的に管理するのに役立ちます。また、セキュリティ ポリシーの早期統合と埋め込みもサポートしており、将来の API に適用できるため、「セキュリティのシフト」を支援し、本番環境に導入されるまでの開発プロセス全体にセキュリティ保護を統合できます。

API 相互接続戦略と API 主導の相互接続戦略の違いは何ですか?

「API 主導の相互接続」は、デジタル変革と企業全体の API 戦略に対する特定のアーキテクチャ アプローチです。階層化されたアプローチを使用して、エンタープライズ API を機能ごとに分類します。

  • システム API は、 記録システムから生データを取得し、それを信頼性の高い方法でアップストリーム API に公開するために使用されます。

  • プロセス API は 複数のダウンストリーム システム API を調整してデータを集約し、ビジネス ロジックをデータに適用します

  • Experience API により、 ユーザー向けのインタラクションが可能になり、モバイルおよび Web アプリケーションで再利用できます

API の分類にどのアーキテクチャ パターンを使用するかに関係なく、API 相互接続は、クラウド ネイティブ環境で API を管理および運用するための包括的なアプローチです。


NGINX の唯一の公式中国語コミュニティ (すべて nginx.org.cn )

NGINX 関連のその他の技術情報、インタラクティブな Q&A、一連のコース、およびイベント リソース: オープンソース コミュニティ公式 Web サイト |  WeChat 公式アカウント

IntelliJ IDEA 2023.3 と JetBrains Family Bucket の年次メジャー バージョン アップデート 新しいコンセプト「防御型プログラミング」: 安定した仕事に就く GitHub.com では 1,200 を超える MySQL ホストが稼働していますが、8.0 にシームレスにアップグレードするにはどうすればよいですか? Stephen Chow の Web3 チームは来月、独立したアプリをリリースする予定ですが、 Firefox は廃止されるのでしょうか? Visual Studio Code 1.85 がリリース、フローティング ウィンドウ 米国 CISA、メモリ セキュリティの脆弱性を排除するために C/C++ の放棄を推奨 余成東 : ファーウェイは来年破壊的製品を発売し、業界の歴史を書き換える TIOBE 12 月: C# は今年のプログラミング言語になると期待される 論文30年前にLei Junが書いた「コンピュータウイルス判定エキスパートシステムの原理と設計」
{{名前}}
{{名前}}

おすすめ

転載: my.oschina.net/u/5246775/blog/10143233