在SOA架構中，單個API應該執行所有操作，或者應將API拆分為多個操作

Question

我們有一個應用程序，它將RESTful API暴露給用於購買項目的UI。 我對API設計有疑問。 讓我們說應該按順序采取以下行動

1. 要選擇購買的物品
2. 接下來給出要傳遞的地址

我的問題是：我們應該設計一個API來同時獲取兩個數據嗎？ 或者我們應該設計兩個API調用 - 一個創建購買記錄，另一個更新要傳遞的地址？

Answer 1

推薦的SOA方法是選擇粗粒度服務，這似乎是最少量的API調用。

但是，從業務角度來看，項目選擇和購買以及項目交付是兩個非常不同的問題，應該是架構中的獨立組件。 對於項目選擇，您需要考慮庫存和定價等內容。 對於送貨地址，您需要考慮用戶地址列表，地址驗證，運輸和稅收。

除了項ID和地址id之間的某些外部關聯之外，這兩個組件不太可能相互作用。 出於這個原因，我建議兩個API調用。 從功能上講，這也可以讓您的API用戶在不重新購買商品的情況下更新送貨地址，將帳單發送到一個地址，將商品發送到另一個地址等。

Answer 2

當您聲明設計RESTful API時，通常首先要設計資源而不是預期的調用。 稍后，可以選擇包含用於優化HTTP請求計數的其他資源的資源表示。

您可能希望選擇以下列方式繼續：

1. 對項目列表資源建模（GET - 列出所有項目，POST - 允許項目創建）/ items /
2. 建模地址列表資源/地址/
3. 為項目實例資源/ items / item / resourceId建模
4. 為地址實例資源/ addresses / address / resourceId建模

現在您可以使用所有資源，您可以考慮使用模式。 您的所有資源都是一般可用的，可以將其混淆。 回答問題的可能方法是：

1. 使用所需的地址詳細信息擴展項目實例資源（粗粒度為lreeder聲明）
2. 將資源/ deliverydetails /建模為包含項目和地址的列表和實例資源，使項目ID或任何用例最適合的查詢交付詳細信息

希望有所幫助！ 順便說一句。 您將使用面向資源的設計自動遵循SOA方法。 接口將自然地滿足您的業務需求和通用性，足以支持更高級的用例。

這是一個很好的例子