2016-07-27 78 views
0

我有一個帶Web API接口的Windows服務。我使用此服務將數據從一個系統上傳到另一個系統。從另一個web api調用web api

我的問題是,其他系統,我必須上傳數據的系統,是一個Web API服務,我不確定是否是一個好主意讓一個web api調用另一個web api調用內。也許我可以直接將數據上傳到該Web API系統,而無需使用Windows服務。

此Windows服務的存在是因爲要上傳數據的程序不需要知道我要上傳數據的位置。在Windows服務上,我可以將Web api更改爲存儲過程以通過配置上傳數據。我正在嘗試創建一個分離系統。注意:存儲過程會將數據上傳到Web API系統中使用的數據庫的其他數據庫。

但是我可以創建一個分離系統,如果Windows服務具有與API接口的其他系統相同的API接口。在我上傳的程序中,我將URL從Windows Service更改爲Web API系統。

您對這種設計有什麼看法?當我可以直接調用web api時調用web api是個好主意嗎?

回答

0

您對這種設計有什麼看法?當我可以直接調用web api時調用web api是個好主意嗎?

它被稱爲服務代理,或網關或外觀。不知道什麼是原始名稱,是誰聲稱的,但使用它沒有任何問題。事實上,將目標服務隱藏在代理之後是非常常見的。如果需要,可以稍後添加其他功能。例如,您可以引入重試邏輯,緩存,負載平衡,新服務調用,自定義錯誤處理甚至是新技術,而不會影響現有用戶。基本上,這是維護服務版本的正確方法。如果您暴露/api/v1/upload並決定引入/api/v2/upload以及其他字段A-Z,則可以將v1隱藏在v2的後面,併發送默認值而不是A-Z。我不是說這是很好的設計,但我相信你已經看到了它。在同步API後面隱藏異步API是另一個例子,雖然不是很好。

0

它取決於你的目的,呼籲從Web API一個WEP API,通常適用於:
- 你需要避免跨域
- 你需要適應性的一些接口,但不希望改變原來的一個
- 你想做一些更多的行動之前做原來的API

在你的情況下,它可以做到這一點。