1 はじめに

ソフトウェア・アズ・ア・サービスとマイクロサービスアーキテクチャの台頭により、RESTful APIは現代のアプリケーションで遍在する存在となっています。Slack、Stripe、AWSなどのサービスは数百ものメソッドを備えた広範なAPIを提供しており、開発者が自身のタスクに適したメソッドの組み合わせを見つけることは大きな課題となっています。

APIphanyは、RESTful APIに特化して設計されたコンポーネントベース合成を通じてこの課題に取り組みます。本システムは、正確なセマンティック型を使用してユーザーの意図を指定し、検索プロセスを導くことで、高水準の仕様からの自動プログラム合成を実現します。

2 背景と関連研究

2.1 コンポーネントベース合成

コンポーネントベースのプログラム合成は、Java、Scala、Haskellなどの言語でAPIを操作するために成功裏に適用されてきました。これらの合成器は、型シグネチャと入出力例を受け取り、API呼び出しを目的の動作で合成するプログラムスニペットを生成します。

2.2 RESTful APIの課題

コンポーネントベース合成をRESTful APIに適用することを複雑にする主な課題が3つあります：(1) API仕様における正確なセマンティック型の欠如、(2) 半構造化データのラングリングの必要性、(3) 合成中のAPI呼び出し実行に関する安全性への懸念です。

3 APIphanyアーキテクチャ

3.1 セマンティック型推論

APIphanyは、REST仕様をセマンティック型で拡張する型推論アルゴリズムを導入します。これにより、ユーザーの意図をより正確に指定でき、合成プロセスをより効果的に導くことができます。

3.2 データラングリング合成

本システムは、RESTful APIを扱う際に一般的に遭遇する半構造化データ（JSONオブジェクトや配列を含む）のラングリングのための効率的な合成技術を含みます。

3.3 シミュレーテッド実行

APIphanyは、合成中に実際のAPI呼び出しを実行することを避けるためにシミュレーテッド実行を採用し、安全性と性能への懸念に対処しながら合成の正確性を維持します。

4 技術的実装

4.1 型システムの形式化

APIphanyの型システムは、標準的な型システムをセマンティックな注釈で拡張します。中核となる型判断は以下のように形式化されます：

$\Gamma \vdash e : \tau \Rightarrow \phi$

ここで、$\Gamma$は型環境、$e$は式、$\tau$は基本型、$\phi$は式の振る舞いを捕捉するセマンティック精緻化です。

4.2 合成アルゴリズム

合成アルゴリズムは、バックトラッキングを伴う型指向検索を使用します。検索空間は以下によって定義されます：

$P := \text{apiCall}(p_1, \dots, p_n) \mid \text{map}(P, \lambda x. P) \mid \text{filter}(P, \lambda x. P) \mid \text{compose}(P, P)$

このアルゴリズムは、型制約とセマンティック精緻化を使用して、無効な候補を早期に刈り込みます。

5 実験的評価

5.1 方法論

APIphanyは、3つの実世界のAPI（Slack、Stripe、GitHub）に対して、GitHubリポジトリとStackOverflowから抽出した32のタスクで評価されました。タスクには、Slackチャネルからメンバーのメールアドレスを取得する、Stripeからの支払いデータを処理するなどの一般的な統合シナリオが含まれていました。

5.2 結果と性能

APIphanyは、32タスク中29タスク（90.6%の成功率）に対して正しい解を見つけることに成功しました。このうち、23の解は合成結果の上位10件以内に報告され、型指向アプローチの有効性が示されました。

成功率

90.6%

29/32 タスク解決

上位10件結果

79.3%

23解決策が上位10件内

平均合成時間

4.2秒

タスクあたり

6 コード例

Slackチャネルメンバーのメールアドレスを取得するための合成タスクの例：

// 入力仕様
型: ChannelName -> List[Email]

// 合成された解決策
function getChannelEmails(channelName) {
  const channels = conversations_list();
  const targetChannel = channels.find(c => c.name === channelName);
  const memberIds = conversations_members(targetChannel.id);
  return memberIds.map(id => {
    const user = users_info(id);
    return user.profile.email;
  });
}

7 将来の応用と方向性

APIphanyのアプローチは、以下のような他の領域に拡張可能です：

  • 型イントロスペクションを伴うGraphQL API合成
  • クラウドネイティブアプリケーションにおけるマイクロサービスオーケストレーション
  • モノのインターネット（IoT）デバイス統合
  • エンタープライズシステム統合とレガシーAPIの近代化

将来の作業には、より良い型推論のための機械学習の統合、および非同期APIパターンへのサポート拡大が含まれます。

8 独自分析

APIphanyは、Web APIのためのプログラム合成における重要な進歩を代表し、従来のアプローチを制限してきた根本的な課題に取り組んでいます。セマンティック型とコンポーネントベース合成の統合は、形式手法と実践的なAPI統合タスクの間のギャップを埋める強力なフレームワークを創出します。

APIphanyの型推論メカニズムは、Liquid Haskell [1]のような言語における精緻型システムとの概念的類似性を共有しますが、これらの概念をREST APIの動的で半構造化された世界に適合させています。この適応は、型が明示的な静的に型付けされた言語とは異なり、REST APIは多くの場合、構造的ではあるがセマンティックな型情報を提供しないJSONスキーマに依存しているため、極めて重要です。

シミュレーテッド実行技術は特に革新的であり、プログラム検証における記号実行 [2] からインスピレーションを得ていますが、それをAPI合成に適用しています。このアプローチは、合成プロセス中に潜在的に破壊的なAPI操作を実行するという重大な安全性の懸念に対処します。同様の技術はデータベースクエリ最適化 [3] で使用されてきましたが、APIphanyはそれらをより複雑なマルチAPIプログラム合成の領域に適合させています。

文字列変換のためのFlashFill [4] やコンポーネントベース合成のためのSyPet [5] のような他の合成アプローチと比較すると、APIphanyはドメイン固有の知識（REST APIセマンティクス）が合成の有効性を劇的に改善できることを示しています。実世界タスクでの90.6%の成功率は、汎用合成器から期待されるものを大幅に上回り、実用的なアプリケーションにはドメインを意識した合成が不可欠であるという仮説を支持します。

データラングリングコンポーネントは、API統合における根本的な課題、すなわちAPIデータ形式とアプリケーション要件の間のインピーダンスミスマッチに対処します。この問題はETL（抽出、変換、ロード）プロセス [6] におけるデータ変換課題を想起させますが、APIphanyは手動指定ではなく合成を通じてこれを解決します。このアプローチは、将来のAPI設計プラクティスに影響を与え、API仕様におけるより体系的な型情報を促進する可能性があります。

今後を見据えると、APIphanyの技術は、APIコード生成のための大規模言語モデルと統合される可能性があります。GPT-3 [7] のようなモデルはコード生成において印象的な能力を示しますが、型指向合成のセマンティックな正確性と安全性保証を欠いています。神経生成と型指向検証を組み合わせたハイブリッドアプローチは、実用的プログラム合成の次のフロンティアを代表する可能性があります。

9 参考文献

  1. Vazou, N., et al. "Refinement types for Haskell." ICFP 2014.
  2. Baldoni, R., et al. "A survey of symbolic execution techniques." ACM Computing Surveys 2018.
  3. Neumann, T. "Efficiently compiling efficient query plans for modern hardware." VLDB 2011.
  4. Gulwani, S. "Automating string processing in spreadsheets using input-output examples." POPL 2011.
  5. Feng, Y., et al. "Component-based synthesis for complex APIs." OOPSLA 2017.
  6. Vassiliadis, P. "A survey of extract-transform-load technology." IJDWM 2009.
  7. Brown, T., et al. "Language models are few-shot learners." NeurIPS 2020.
  8. Polikarpova, N., et al. "Program synthesis from polymorphic refinement types." PLDI 2016.