ブログ

API アーキテクチャの習得: API の基礎

バイロン・マクノートのサムネイル
バイロン・マクノート
2022年12月5日公開


applicationプログラミング インターフェイス (API) が大流行しています。

応援する

API 自体は新しいものではありませんが、COVID-19 によるデジタル トランスフォーメーションの加速、ソフトウェア統合の強化、レガシー アプリをクラウド向けに再プラットフォーム化する取り組みなどの最近の現象により、 API が継続的に拡大し、現代のデジタル経済で成功するために組織が行う管理、セキュリティ、さらにはアーキテクチャの選択にも影響を与えています。

本質的に、API はマシンの台頭を表すことができます。 ただし、幸いなことに、人間は依然としてそれらの構築、管理、セキュリティを制御できます (少なくとも今のところは)。

ロボット

基本的に、「API スピーク」では、コンシューマーは通常、さまざまな標準、スキーマ、仕様で構成される統一されたインターフェースを介して、プロデューサーにクエリまたはリクエストを送信します。

たとえば、国立気象局 (プロデューサー) には毎日の天気データが含まれています。 携帯電話の天気アプリ (消費者) は、 WeatherKit REST APIを介してこのシステムを呼び出す (より具体的にはクエリを実行する) し、天気アプリのユーザー インターフェイスを通じてデータをレンダリングします。 これは、何百万人ものユーザーが使用する人気アプリの単純な例ですが、マシン間通信が現代のデジタル エクスペリエンスのトラフィックの大部分を占めており、それが API によって実現されていることは注目に値します。

ライオン

API によってもたらされるビジネス価値につながる技術的な利点は数多くあります。

テクノロジーのメリット ビジネス価値
Web アプリの基礎となる実装を抽象化します。 組織はモバイル アプリとマイクロサービス ベースのアーキテクチャを迅速に導入できます。
開発者がツールを使用して API コンシューマーを実装できるように、タイプを指定します。 リーダーは開発プロセスを最適化して、市場投入までの時間を短縮できます。
一貫性があり予測可能な情報交換をモデル化するためにセマンティクス/動作を定義します。 パートナーはサードパーティ統合を開発し、収益化することができます。

API の実装に関しては、考慮すべき点がいくつかあります。 具体的には、モデリング、バージョン管理、契約テストに関して、依存関係を切り離し、設計、構築、保守中の相互運用性を確保するのに役立ちます。

考慮 説明 利点
モデリング 情報の交換を表現し構造化するセマンティクスまたは動作。 分散アーキテクチャの合理化された管理。
バージョン管理 API ライフサイクル全体にわたるリリースとメンテナンスのガバナンス戦略。 最大限の使いやすさと下位互換性。
契約テスト 消費者と生産者の間の定義された相互作用と期待される応答。 サードパーティのビジネス統合との決定論的な相互作用。

API を構築、管理、保護する方法に正解も不正解もありません。実際、API が普及し始めると、大規模に API を使用するには API の形状と構造を標準化する必要が生じました。 OpenAPIイニシアチブとその結果生まれた OpenAPI 仕様 (OAS) を紹介します。 Swagger はOpenAPI 仕様の元々のリファレンス実装であり、現在ではほとんどのツールが OpenAPI の使用に収束していますが、OpenAPI は依然として Swagger を維持しています (HA!)

実際、API はさまざまな標準、スキーマ、仕様を使用して構築できます。 たとえば、 RESTfulプレゼンテーション、 gRPCサービス、 GraphQLスキーマへの接続などです。

実装 概要 利点 使用する場合


REpresentation State Transfer (REST) は、統合インターフェースを記述するための軽量なアーキテクチャ モデルを提供します。最も一般的には、基盤となるトランスポート プロトコルとして HTTP を使用して適用されます。

REST は、API ベースのアーキテクチャの実装として、これまでで最も広く導入されています。

Postman 2022 API の現状レポート

  • REST には非常に基本的なルールがあり、参入障壁が低く、ドメイン モデルが強力であるため、実装が比較的簡単です。
  • 階層化システムであるため、REST インターフェースの背後にあるシステムの複雑さが抽象化されます。 たとえば、消費者は、Web サービスの背後にあるデータベース システムと対話していることに気づいていません。
  • REST は、コンテンツ タイプ (JSON や YAML を含む) を柔軟にサポートします。
  • OpenAPI 仕様が API の形状と構造を消費者と共有するのに十分な場合。
  • プロデューサーからコンシューマーへのリクエストはデフォルトではステートレスであるため、HTTP ヘッダーに基づいてキャッシュを動的に決定する必要がある場合。
  • プロデューサーが提供する単一の API のリソース モデルを拡張する場合、または API ゲートウェイを使用して同じベース URL で複数の API を提供する場合。


GraphQL は、API 用のオープンソースのデータ クエリおよび操作言語であり、既存のデータを使用してそれらのクエリを実行するためのランタイムです (Facebook によって開発され、現在は Linux Foundation の一部となっています)。
  • 複数のソースにわたってクエリを実行するためのクエリ言語を提供します。 
  • 複数の API にまたがるフィールドを含め、クライアントが必要なフィールドを正確に要求できるようにすることで、初回読み込み時間を短縮します。
  • スキーマ言語は、個々の API のタイプと API の組み合わせ方法を指定し、すべての API にわたって単一のバージョンを提供できるようにして、バージョン管理を簡素化します。
  • 複雑さを抽象化するために既存のレガシー システムに配置される補完的なテクノロジーとして。 
  • API コンシューマーが、相互接続された広範囲のサービスにわたって均一なアクセス、フィルタリング、およびクエリを必要とする場合。
  • モバイル デバイスでは、画面が小さく、ネットワークの可用性に制約があります。


gRPC は、Linux Foundation の管理下にある、最新のオープンソースの高性能リモート プロシージャ コール (RPC) フレームワークです。
  • HTTP/2、軽量プロトコル バッファ、シリアル化されたペイロード、ステートフル実装の使用により、高いパフォーマンスと信頼性を実現します。
  • 負荷分散、トレース、ヘルスチェック、認証のプラグ可能なサポート。
  • すべての言語に対応する豊富なツールサポートを備えた、高度なインターフェース機能とメッセージの相互運用性。 
  • 分散コンピューティングのラストマイルとして、デバイス、モバイル アプリ、ブラウザーをバックエンドのマイクロサービスに接続し、モバイルとデスクトップ/IoT のやり取りを行うクロスプラットフォーム アプリを実現します。
  • コンテナ間トラフィック(「東西」)用。
  • ストリーミングを必要とする外部インターフェース(「North-South」)や、チャット、金融、ニュースなどのストリーミング アプリ向け。 

API の基礎に関する入門書を踏まえて、今後の投稿では、レガシー アプリをクラウド用に再プラットフォーム化してすべてをまとめる前に、API アーキテクチャを構築、管理、保護する方法を探ります。

アプリ保護

先に進みたいですか? 今すぐ電子書籍をダウンロードしてください:

API アーキテクチャをマスターする | O'Reilly eBook