ForgeVision Engineer Blog

フォージビジョン エンジニア ブログ

【図解あり】API Gatewayの構築概念とルーティングについて詳しく調査してみた

AWS API Gateway

こんにちは。フォージビジョンの藤川と申します。

少し前になりますが、Amazon API Gatewayについて、2021/3/30に「Amazon API Gatewayのカスタムドメイン名がマルチレベルのベースパスマッピングをサポート開始」の発表がありました。

aws.amazon.com

この度、Amazon API Gatewayを勉強する機会があり、API Gatewayの構築概念やルーティングの仕様について学び直した点がありましたので、記事にさせていただきたいと思います。

概要

この記事では、Amazon API Gatewayに関する以下の2点について記載させていただきます。

  1. Amazon API Gatewayを構築する際に構成要素として、API、リソース、メソッドがありますが、機能ごとにどのように構成していくのが良いのか（APIごとに分けるか、もしくはリソースごとに分けるかなど）？
  2. 2021/3/30に「Amazon API Gatewayのカスタムドメイン名がマルチレベルのベースパスマッピングをサポート開始」されましたが、ルーティングの順番やロンゲストマッチの単位はどのようになっているか？

1. 構築概念について

Amazon API Gatewayを構築する際に構成要素として、API、リソース、メソッドがありますが、機能ごとにどのように構成していくのが良いのかという疑問にぶつかりました。これは、Amazon API Gatewayがどのような思想（考え）のもとに作成されたかを紐解くことで解消することができました。

1.1 Amazon API Gatewayの考え方

開発ありきでAmazon API Gatewayが作成されたと考えた場合

Amazon API Gatewayは、開発ありきで作成されたものです。この考えをもとにAPIの構成を考えてみると、「利用用途を考えて、その利用用途に見合った機能を考えていく」という順番となります。このため、必然的に 「API 数 = 利用用途数」となります。

この場合、Amazon API Gatewayの構成（カスタムドメインを用いる場合）は、以下のようになるかと思います。

＜特徴＞

  • 利用用途ごとにAPIを作成し、1 つの API に対して、複数の機能をファイルパスで分類し、設定する。
  • カスタムドメイン化する際には、複数の機能のグループ毎に API マッピングを設定するだけで済む。

以上のことから、APIマッピングする個数は最小限に抑えることができ、オープンAPIを実施される際に最小限のAPIを意識するだけで済みますので、オープンAPIを利用するユーザーの対応が容易になる傾向があります。

API Gateway ありきで開発することを考えた場合

では逆に、API Gateway ありきで開発することを考えると、「すでに機能が存在している中で、利用用途を考えていく」という順番となりますので、必然的に 「API 数 = 機能数」となります。

この場合、Amazon API Gatewayの構成（カスタムドメインを用いる場合）は、以下のようになるかと思います。

＜特徴＞

  • 1 つの API に対して、1 つの機能を設定されている。 ※ 機能ごとに FQDN （ホスト名）が異なっている状況。
  • このため、カスタムドメイン化する際に、機能毎に API マッピングを設定する必要がある。
  • 機能ごとに FQDN （ホスト名）が異なっている状況を 1 つの API に対して 1 つの API マッピングを設定することで機能ごとにファイルパスで分類できるようにされている。

以上のことから、 1 つの API に対して 1 つの API マッピングを設定する必要があり、管理が煩雑となること、オープンAPIを実施される際に複数のAPIを意識させる必要があり、オープンAPIを利用するユーザーの対応が難しくなる傾向があります。

2.ルーティングの仕様について

「Amazon API Gatewayのカスタムドメイン名がマルチレベルのベースパスマッピングをサポート開始」されましたが、以下のルーティングの仕様に関する疑問にぶつかりました。
（１）ロンゲストマッチの単位（文字単位 or パスの階層単位）
（２）ルーティングの順番（APIマッピングが先 or APIのごとのリソースが先）

AWS サポートセンターに確認させていただいた内容をもとに記載させていただきます。
※前提として、この度はREST APIを対象としています。

2.1 ロンゲストマッチの単位

以下のページには、APIリクエストのルーティングについて、「最も長い一致パスを持つ API マッピングにリクエストをルーティングします。」と記載があります。いわゆる、ロンゲストマッチを指しているかと思いますが、ロンゲストマッチの単位についてはどうなのかという疑問が浮かびました。

docs.aws.amazon.com

AWSサポートセンターからのご回答

ロンゲストマッチに関するAWSサポートセンターの回答は、以下の通りです。

文字列単位ではないため、パスの階層単位でルーティングされます。

例題

次の API マッピングを持つカスタムドメイン名「https://api.example.com」を考えています。

  • API 1 にマッピングされている (none)。
  • API 2 にマッピングされている orders/v1/items。
  • API 3 にマッピングされている orders/v2/items。
  • API 4 にマッピングされている orders/v2/items/categories。

このとき、「https://api.example.com/orders/v2/items/cate」をリクエストした場合、パスの階層単位でルーティングされますので、この場合はAPI3にルーティングされます。

2.2 ルーティングの順番

「Amazon API Gatewayのカスタムドメイン名がマルチレベルのベースパスマッピングをサポート開始」となり、APIマッピングでも階層構造があり、APIの中でも階層構造がある状態となりました。そうした場合に、どのような順番で合致するパスを探索するのかという疑問が浮かびました。

AWSサポートセンターからのご回答

ルーティングの順番に関するAWSサポートセンターの回答は、以下の通りです。

REST API のルーティングの大まかな流れとしてはAPIマッピングでルーティングするステージが定まり、 その後対象の API、ステージにてパスが判定されます。

例題

次の API マッピングを持つカスタムドメイン名「https://api.example.com」を考えています。

「https://api.example.com/FV/Item1」をリクエストした場合

  1. APIマッピングの設定値（パス）の中から、「/FV/Item1」に一致するものを検索します。
  2. 「/FV/Item1」は、API「B」と一致しますので、API「B」の処理が実行されます。

「https://api.example.com/FV/fv-detail」をリクエストした場合

  1. API マッピングの設定値（パス）の中から、「/FV/fv-detail」に一致するものを検索します。
  2. 「/FV/fv-detail」はAPIマッピングの設定値（パス）には存在しないので、/FV のAPI「A」が選択されます。
  3. API「A」の設定で、/fv-detail が存在しますので、API「A」の /fv-detail リソースの処理が実行されます。

最後に

紙面上で勉強することも大切ですが、実際に触って、壁にぶつかったことについて勉強する方が身につきますね。API Gateway以外にも壁にぶち当たることがありましたら、今後も記事にしていきたいと思います。