APIアーキテクチャを極める：APIの基礎

F5エコシステム | 2022年12月05日

Byron McNaughtシニアソリューションマーケティングマネージャー | F5

アプリケーションプログラミングインターフェース（API）が大きな注目を集めています。

API自体は新しいものではありませんが、COVID-19の流行下で加速したデジタルトランスフォーメーション、ソフトウェア統合の高度化、レガシーアプリをクラウド向けに再プラットフォーム化する取り組みといった近年の動向により、APIの無秩序な増加が続いています。その影響は、管理やセキュリティにとどまらず、現代のデジタル経済で成功するために組織が行うアーキテクチャ上の選択にまで及んでいます。

APIは本質的に、機械の台頭を象徴する存在ともいえます。ただし幸いなことに、その構築、管理、セキュリティは、少なくとも今のところ、まだ人間が制御しています。

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

たとえば、National Weather Service（プロデューサー）には、日々の気象データが蓄積されています。スマートフォンの天気予報アプリ（コンシューマー）は、WeatherKit REST APIを介してこのシステムを呼び出し、より正確にはクエリを送信して、取得したデータを天気予報アプリのユーザーインターフェースに表示します。これは、数百万人のユーザーが利用する人気アプリのわかりやすい例ですが、現代のデジタルエクスペリエンスにおけるトラフィックの大半はマシン間通信が占めており、それを支えているのがAPIである点は注目に値します。

APIには、ビジネス価値につながるさまざまな技術的メリットがあります。

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

APIの実装にあたっては、さまざまな点を考慮する必要があります。特に、設計、構築、保守の各段階で依存関係を分離し、相互運用性を確保するうえで役立つ、モデリング、バージョニング、コントラクトテストについて検討します。

考慮事項	説明	メリット
モデリング	情報交換を表現し、構造化するためのセマンティクスまたは動作。	分散アーキテクチャの管理を効率化します。
バージョン管理	APIライフサイクル全体にわたるリリースとメンテナンスのガバナンス戦略。	最大限の使いやすさと後方互換性。
コントラクトテスト	コンシューマーとプロデューサー間の定義済みのインタラクションと期待される応答。	サードパーティのビジネス統合との確定的な連携。

APIの構築、管理、セキュリティ確保に、唯一の正解や間違いがあるわけではありません。実際、APIが普及し始めると、大規模に利用できるよう、APIの形式と構造を標準化する必要が生じました。そこで登場したのが、OpenAPI Initiativeと、そこから生まれたOpenAPI Specification（OAS）です。SwaggerはOpenAPI Specificationの最初のリファレンス実装でした。現在では、ほとんどのツールがOpenAPIの使用に集約されていますが、そのswagger（威勢）は今も健在です（笑）。

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

実装

概要

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

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

Postman 2022 State of the API Report

メリット

RESTのルールは非常に基本的で、導入のハードルが低く、ドメインモデルも堅牢なため、比較的容易に実装できます。
階層化システムであるため、RESTインターフェースの背後にあるシステムの複雑さは抽象化されます。たとえば、利用者はWebサービスの背後にあるデータベースシステムとやり取りしていることを意識する必要がありません。
RESTは、JSONやYAMLを含むコンテンツタイプを柔軟にサポートしています。

使用するタイミング

APIの形式と構造を利用者と共有するうえで、OpenAPI仕様で十分な場合。
プロデューサーからコンシューマーへのリクエストはデフォルトでステートレスであるため、HTTPヘッダーに基づいてキャッシュの要否を動的に判断する必要がある場合。
プロデューサーが提供する単一APIのリソースモデルを拡張する場合、またはAPI Gatewayを使用して同じベースURLで複数のAPIを提供する場合。

GraphQLは、API向けのオープンソースのデータクエリおよび操作言語であり、既存のデータを使用してクエリを実行するためのランタイムでもあります（Facebookが開発し、現在はLinux Foundationの一部です）。

複数のソースを横断してクエリを実行できるクエリ言語を提供します。
クライアントは、複数のAPIにまたがるフィールドを含め、必要なフィールドだけを指定してリクエストできるため、初回読み込み時間を短縮できます。
スキーマ言語で個々のAPIの型とAPIの組み合わせ方を定義することで、すべてのAPIに単一のバージョンを適用でき、バージョン管理を簡素化できます。

既存のレガシーシステム上に配置し、複雑さを抽象化する補完的なテクノロジーとして。
相互接続された幅広いサービスに対して、APIコンシューマーが統一されたアクセス、フィルタリング、クエリを必要とする場合。
画面サイズやネットワークの可用性に制約があるモバイルデバイスで使用する場合。

gRPCは、Linux Foundationの管理下にある、最新のオープンソースの高性能リモートプロシージャコール（RPC）フレームワークです。

HTTP/2、軽量なプロトコルバッファ、シリアライズされたペイロード、ステートフルな実装を使用することで、高いパフォーマンスと信頼性を実現します。
ロードバランシング、トレーシング、ヘルスチェック、認証をプラグイン形式でサポート。
すべての言語に対応する豊富なツールサポートにより、インターフェース機能とメッセージの高い相互運用性を実現します。

分散コンピューティングのラストマイルで、デバイス、モバイルアプリ、ブラウザをバックエンドのマイクロサービスに接続する場合や、モバイルとデスクトップ／IoTが連携するクロスプラットフォームアプリに適しています。
コンテナ間トラフィック（「East-West」）向け。
ストリーミングを必要とする外部インターフェース（「North-South」）や、チャット、金融、ニュースなどのストリーミングアプリ向け。

ここまで解説したAPIの基礎を踏まえ、今後の記事ではAPIアーキテクチャの構築、管理、セキュリティ確保について取り上げます。その後、これらを総合的に活用し、レガシーアプリをクラウド向けにリプラットフォームする方法を解説します。