1 簡介

隨着軟件即服務同微服務架構嘅興起，RESTful API 已經成為現代應用程式無處不在嘅一部分。好似 Slack、Stripe 同 AWS 等服務提供咗數百種方法嘅廣泛 API，為開發者搵到適合任務嘅方法組合帶嚟咗重大挑戰。

APIphany 透過專門為 RESTful API 設計嘅基於組件合成技術嚟應對呢個挑戰。該系統使用精確嘅語義類型嚟指定用戶意圖並指導搜索過程，從而實現從高層次規範自動化程式合成。

2 背景與相關工作

2.1 基於組件嘅合成

基於組件嘅程式合成已經成功應用於 Java、Scala 同 Haskell 等語言中嘅 API 導航。呢啲合成器採用類型簽名同輸入輸出示例嚟生成組合 API 調用並具有所需行為嘅程式片段。

2.2 RESTful API 挑戰

三個主要挑戰令到將基於組件嘅合成應用於 RESTful API 變得複雜：(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 喺三個真實世界 API（Slack、Stripe、GitHub）上進行評估，並從 GitHub 倉庫同 StackOverflow 提取咗 32 個任務。任務包括常見嘅集成場景，例如從 Slack 頻道檢索成員電郵同處理 Stripe 嘅支付數據。

5.2 結果與性能

APIphany 成功喺 32 個任務中搵到咗 29 個正確解決方案（成功率 90.6%）。其中，23 個解決方案被報告為前十個合成結果，證明咗類型導向方法嘅有效性。

成功率

90.6%

29/32 任務已解決

前十結果

79.3%

23 個解決方案喺前十

平均合成時間

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 代表咗網絡 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.