如果我在 Golang 中開發 Booking REST 服務（即包預訂）。在允許業務操作的情況下創建 BookingClient 接口（由結構支持）是一種“GO 方式”，以便我的寧靜服務的客戶端將使用 BookingClient（從包預訂導入）而不是直接發送 http 請求？
3 回答
GCT1015
TA貢獻1827條經驗 獲得超4個贊
一般來說，不 - 如果您提供特定語言的客戶端，那只會是一種方便，因此（某些）用戶可以更輕松地使用您的 API。這當然假設您的客戶端設計良好。我不會僅僅在 Go 中提供一個接口來指示一組可能的 API 調用。這將有利于非常狹窄的受眾范圍，可能對于那些自己為您的 API 開發客戶端的人來說，使用恰好與您的服務器的實現相同的編程語言。即便如此，他們可能并不真正喜歡使用接口的想法（例如，他們可能只需要一組特定的方法）。
如果你想為你的 API 提供一個客戶端，繼續做，但是將它與實際的服務器分開（不同的包，甚至可能是不同的 repo）。一般來說，人們通過 HTTP 開發 API 以允許廣泛的客戶端訪問它，可以用任何語言編寫。我不會提供一些接口，而是將時間花在編寫好的文檔上。
在我看來，假設沒有提供更多上下文，您的問題的答案應該沒有什么不同，如果您問自己是否應該在 Python 中提供客戶端。但是，例如，如果您的 API 由您的公司內部使用并且您主要使用 Go 進行開發，那么整個情況可能會發生變化。
開滿天機
TA貢獻1786條經驗 獲得超13個贊
測試在 Go 中很重要，所以編寫可測試的代碼是你應該做的事情。如果您使用直接 http 請求，與使用模擬結構相比，您將更難編寫單元測試。
是否有任何理由使用 aClient而不是調用調用 REST 端點的函數？模擬一個更大的東西通常更難，比如一個 Client 結構，而不是一組小函數。
您應該將客戶booking.Client置于 避免重復自己 ( booking.BookingClient) 并可能重命名Client為更具描述性的名稱。
海綿寶寶撒
TA貢獻1809條經驗 獲得超8個贊
通常最好這樣做，大多數公司都這樣做，但提供直接使用 API 的文檔。主要用例是人們使用與您想要的語言不同的語言。
你可以看看我寫的一個新的 RESTful 框架，它包括使用 Go 模板自動編譯客戶端的基礎設施，盡管我還沒有編寫 Go 客戶端編譯器。如果你想寫一個，將不勝感激:) https://github.com/EverythingMe/vertex
- 3 回答
- 0 關注
- 263 瀏覽
添加回答
舉報
0/150
提交
取消