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 合成
  • 雲端原生應用中的微服務協調
  • 物聯網裝置整合
  • 企業系統整合與傳統 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.