一直以來都是用 NSwag 來產生 OpenAPI Client & Server Code,但它所產生出來的 Client Code 會 throw Exception,這讓我在商業流程的控制需要額外付出一些心力,為了解決這問題,我會額外再墊一層,最近逛到有人分享 Refit 這個套件,它所產生出來的具名 Method 不會拋出例外,讓我可以根據 HttpStatusCode + Error Content 控制商業流程。
如何使用 Swagger/OpenAPI Specification + Prism 建立基於合約的 Mock Server
- 1540
- 0
- API Specification
- 2024-02-24
在介接其他人寫的 Web API 時,可以透過 Mock Server 來模擬對方會回傳的資料,比如說 json-server,但這樣往往會因為兩造之間沒有一個合約、規範,各自實作,導致最後在整合的時落差太大;理論上,雙方基於合約、規範,進行開發,最後在整合的時候應該有問題的狀況應該會小一點,Prism 是套基於 Swagger/OpenAPI Specification 的 Mock Server,在 OpenAPI 的生態系裡面算是蠻完整的解決方案之一,接下來,是我對它在使用上的小小心得。
如何模組化 Swagger / OpenAPI Specification 檔案
- 1101
- 0
- API Specification
- 2022-07-27
當我們的 Swagger / OpenAPI Specification 寫到某一個程度就會開始想要模組化、重用它,例如,當 components/schemas 節點需要被其他的檔案參照。
如何使用 Swagger / OpenAPI Specification 先行的開發流程
- 4391
- 0
- API Specification
- 2022-10-05
以往,在 ASP.NET Fx / ASP.NET Core 我會先寫好 Controller(Server Code) 再搭配 NSwag、Swashbuckle.AspCore 產生 Swagger / OpenAPI Specification Doc,一旦要修改它(Spec.)就必須要重新編譯專案,只是要改文件的錯字,也沒有動到 Server Code 的邏輯,卻要重新 Build Server,幾次下來發現這樣似乎不是很聰明。也常常發生過於關注 Server Code 忽略 Specification ,導致兩邊跟不一致。
現在,我先寫 Specification,然後再透過它產生 Controller (Server Code) 讓 Specification 不再強制依賴 Server Code,解除強依賴關係,編寫規範時再也不需要重新建置專案,目前運作起來挺順暢的,接下來,我分享我是怎麼做的
- 1