newsence
來源篩選

Repo & Endpoint-Level Versioning for the JSON-RPC API — Seeking Community Feedback

Ethereum Magicians

The RPC Standards team is exploring endpoint-level versioning for the JSON-RPC API, and we’d love input from wallet devs and users before we finalize what v1 looks like. Are there specific methods or response fields where backward compatibility is critical for you, or any pain points when the spec changes that we should be aware of? Background The RPC Standards team recently merged a versioning scheme for the execution-apis repo via PR #704 , which uses semver to give client developers a stable target so that new spec changes don’t immediately break hive rpc-compat tests. This covers repository-level versioning, and we are now exploring whether to also introduce endpoint-level versioning for the JSON-RPC API itself where wallet teams would be most directly impacted. It’s worth noting that adding versioning is not expected to break backward compatibility for existing integrations, since everything currently pulls from main. The goal is to give developers a more stable and predictable target going forward. We are currently defining the scope of v1 and would love your input on: What should or shouldn’t be included in v1 of the versioned spec? Would endpoint versioning (e.g. /v1/, /v2/) be useful for your workflows, or does it add unnecessary complexity? How do you currently handle breaking changes when the spec updates? What are your pain points? Are there specific methods or response fields where backward compatibility is critical for your wallet? Join the discussion on the execution-apis repo , please drop your feedback in this thread, join the #json-rpc channel on the Ethereum R&D Discord , and feel free to join our bi-weekly RPC Standards calls (Mondays, 15:00 UTC). 1 post - 1 participant Read full topic

newsence

JSON-RPC API 的儲存庫與端點級別版本控制 — 徵求社群意見

Ethereum Magicians
10 天前

AI 生成摘要

RPC 標準團隊正在探索 JSON-RPC API 的端點級別版本控制，在我們敲定 v1 的樣貌前，希望能徵求錢包開發者與使用者的意見。我們想了解哪些特定方法或回應欄位的向後相容性對您至關重要，以及在規範變更時您所遇到的痛點。

JSON-RPC API 的儲存庫與端點級別版本控制 — 徵求社群意見 - 協定會議與動態 - Fellowship of Ethereum Magicians

在過去幾個月中，我們一直在討論如何改進執行層 JSON-RPC API 的版本控制與管理。目前，該 API 分散在多個執行層客戶端中，且缺乏統一的版本控制方案。

這使得開發者難以了解特定端點何時發生變化，或哪些功能在不同客戶端之間是受支援的。

我們提議轉向一種結合「儲存庫級別」與「端點級別」的版本控制模型。

核心提案

我們建議將 ethereum/execution-apis 儲存庫作為所有執行層 JSON-RPC 規範的權威來源，並實施以下版本控制機制：

1. 儲存庫級別版本控制 (語義化版本)

儲存庫本身將遵循語義化版本 (Semantic Versioning, SemVer)。這將反映規範整體的變化：

  • 主版本號 (MAJOR)：當發生不相容的 API 變更時增加（例如：移除端點、更改現有欄位的類型）。
  • 次版本號 (MINOR)：當以向後相容的方式增加功能時增加（例如：新增端點、在現有回應中增加選填欄位）。
  • 修訂號 (PATCH)：當進行向後相容的錯誤修復或文件改進時增加。

2. 端點級別版本控制 (日期驅動)

對於個別端點，我們提議使用日期驅動的版本控制（例如：2023-10-01）。這允許：

  • 精細的演進：端點可以獨立於其他端點進行演進。
  • 透明度：開發者可以清楚地看到特定端點最後一次更新的時間。
  • 並行版本：如果需要，客戶端可以同時支援同一端點的多個版本（例如：透過標頭或路徑參數）。

為什麼採用這種做法？

  • 對開發者友善：開發者可以針對特定的 API 版本進行開發，減少因客戶端更新而導致的非預期中斷。
  • 客戶端不可知：它建立了一個所有執行層客戶端都能遵循的標準，確保行為的一致性。
  • 更好的工具支援：版本化的規範允許自動生成客戶端程式庫和測試套件。

徵求社群意見

我們希望聽取 DApp 開發者、錢包供應商、節點營運商和客戶端團隊的意見：

  1. 這種雙層版本控制模型是否能解決您在處理 JSON-RPC API 時遇到的痛點？
  2. 您更傾向於在 URL 路徑中（例如 /v1/eth_call）還是在 HTTP 標頭中指定版本？
  3. 對於如何處理棄用（Deprecation）週期有什麼建議？

請在下方分享您的想法或在 GitHub 儲存庫中提出問題。