我們正在徹底檢查我們的前端和后端服務合同的可靠性，并正在調查兩種似乎有沖突的工具/技術。使用諸如openapi 生成器之類的工具從 OpenAPI 規范 (OAS) 生成消費者和提供者代碼與使用諸如pact之類的工具進行消費者驅動合同 (CDC) 測驗。
OAS 代碼生成
OAS 非常適合生成消費者代碼，我們正在努力集成提供商端生成以完成雙方的合同信心。只要合同變更開始于 OAS 并且提供者和消費者生成他們的代碼，這是一個合適的策略嗎？
契約單元測驗
Pact CDC 測驗似乎根本不涉及 OAS，而是通過單元測驗以編程方式在消費者和提供者之間建立合同。在使用協議代理時，添加can-i-deploy工具似乎是對 ci/cd 管道的一個很好的補充。w/pact 的一件好事是它似乎支持 kafka 事件模擬，這將是 openapi-generator 沒有涵蓋的內容。
如果每個服務，無論是前臺還是后臺，都在使用 OAS 代碼生成，那么協議有用嗎？我可以在沒有代碼生成的環境中看到它的實用性，但在其他方面開始感到多余/沖突。
感謝您提供的任何見解或軼事！
uj5u.com熱心網友回復：
Pact 是一個合同測驗框架，它通過示例使用規范來確保提供者實際實作消費者的需求。這消除了歧義，但需要付出代價（撰寫/維護測驗）。需要注意的是，這里的現狀是端到端測驗，比合約測驗更昂貴（為此目的）。
本文討論了模式之間的差異以及它們與合同測驗的關系，以及它們如何一起使用。
如果每個服務，無論是前臺還是后臺，都在使用 OAS 代碼生成，那么協議有用嗎？
這里的簡短回答是，您如何確保您的消費者和提供者的兼容版本是同步的？如果您的提供程式版本之間存在重大更改，您現在需要同步所有消費者的發布。如果發布有問題，那么你需要把它全部扭轉——這是合約測驗解決的一個關鍵問題。
Pact CDC 測驗似乎根本不涉及 OAS
Pactflow 具有將這兩種方法結合起來的功能，但此處概述了其背后的理念
在使用協議代理時，添加 can-i-deploy 工具似乎是對 ci/cd 管道的一個很好的補充。w/pact 的一件好事是它似乎支持 kafka 事件模擬，這將是 openapi-generator 沒有涵蓋的內容。
是的，這更多是 Pact Broker 和 Pact 生態系統的實際好處。如果您需要擴展 REST（以及 OAS 可以記錄的內容），您將需要不同的策略。對于這些用例，Pact 可能更通用。
轉載請註明出處，本文鏈接：https://www.uj5u.com/yidong/460044.html