BLOG

APIアーキテクチャについて学ぶ:APIの基礎

Byron McNaught サムネール
Byron McNaught
Published December 05, 2022
  • Share to Facebook
  • Share to Twitter
  • Share to Linkedin
  • Share via AddThis


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

Cheer

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

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

Robot

基本的には、(言うなれば)「APIの会話」において、コンシューマーは通常、さまざまな規格、スキーマ、仕様で構成される統一インターフェイスを介して、クエリや要求をプロデューサーに送ります。

例えば、National Weather Service(アメリカ国立気象局、プロデューサー)には毎日の気象データがあります。スマートフォンの天気アプリ(コンシューマー)は、WeatherKit REST APIを介してこのシステムを呼び出し(つまり、クエリを実行し)、天気アプリのユーザー インターフェイスを介してデータを表示します。これは、何百万人ものユーザーが使用する一般向けのアプリの単純な例ですが、最新のデジタル エクスペリエンスのトラフィックの大部分を占めるマシン間通信が、APIによって支えられていることは注目に値します。

Lion

以下に示すように、APIがもたらすビジネス価値につながる多くの技術的メリットがあります

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

APIの実装については、多くの考慮事項があります。具体的には、モデル化、バージョン管理、コントラクト テストに関するものであり、これらは設計、構築、メンテナンス時に依存関係を切り離し、相互運用性を確保するのに役立ちます。

考慮事項 説明 メリット
モデル化 情報の交換を表し、構造化するためのセマンティック/動作。 分散型アーキテクチャの効率的な管理。
バージョン管理 APIライフサイクル全体にわたるリリースとメンテナンスのガバナンス戦略。 有用性と下位互換性を最大化。
コントラクト テスト コンシューマーとプロデューサーの間で行われる定義済みのインタラクションと予想される応答。 サードパーティのビジネス統合との確定的なインタラクション。

APIを構築、管理、保護する方法に正解も不正解もありません。実際には、APIが急増し始めてから、APIを大規模に利用するためにAPIの形式と構造の標準化が必要になったのです。そこでOpenAPIイニシアティブが創設され、OpenAPI仕様(OAS)が生まれました。SwaggerはOpenAPI仕様の最初の参照実装です。現在はほとんどのツールがOpenAPIを使用していますが、依然としてSwaggerは維持されています(笑ってしまいますね!)。

実際、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間のインタラクションがあるクロスプラットフォーム アプリに使用する場合。
  • 内部コンテナ トラフィック(「東西」)に使用する場合。
  • ストリーミングを必要とする外部インターフェイス(「南北」)を使用する場合や、チャット、財務、ニュースなどのストリーミング アプリに使用する場合。

これらのAPIの基礎を踏まえて、今後の記事では、レガシー アプリをクラウド用に再プラットフォーム化することですべてをまとめる前にAPIアーキテクチャを構築、管理、保護する方法を紹介していきます。

アプリの保護

成功を収めるには、今すぐEブックをダウンロードしてください。

APIアーキテクチャについて学ぶ | O'Reilly Eブック