什麼是API客戶端的良好體系結構？

Question

我將從頭開始創建一個REST API的PHP客戶端。我考慮使用Guzzle library。

我認爲用戶不應該像處理請求對象（甚至是來自自定義的xxxRequest類）那樣處理傳輸事件，而應該只處理業務對象/服務類。但可能是我錯了......

以下是一些可能的架構示例。哪些方面是最佳做法，爲什麼？
隨意改善它們或建議更好的方法。

---

例1：

class ApiClient { 
    function createBooking (BookingEntity $booking, CustomerEntity $customer) { 
     //... 
    } 
} 

這個例子允許用戶僅使用業務對象，但ApiClient類API是否需要很多方法可以開始髒...除了如果我們想添加功能，必須修改ApiClient。

---

實施例2：

class ApiClient { 
    function execute(CreateBookingRequest $createBookingRequest) { 
     //... 
    } 
} 

class CreateBookingRequest { 
    private BookingEntity $booking; 
    private CustomerEntity $customer; 
    private $queryParams; 

    public createQueryParams() { 
     // to create the query params (from the attibutes) for the http client 
    } 
} 

在這裏，如果一個新的特徵是需要ApiClient還沒有被修改，僅僅一類新的具有被創建。但是用戶必須處理使用Request後綴命名的類。海事組織他不知道任何關於請求或技術的事情。

---

實施例3：

class BookingService { 
    function createBooking (BookingEntity $booking, CustomerEntity $customer) { 
    //... 
    } 
} 

該實施例增加一個層。

---

在所有情況下，ApiClient/Service類中的哪個應該是Guzzle httpClient屬性？或者ApiClient類應該擴展Guzzle客戶端類嗎？

Answer 1

那麼，那裏並沒有真正的標準，但這絕對是一個熱門話題，我甚至會說，這不是Guzzle特有的。

簡答：我會根據API的複雜性選擇選項1和3。

更長的答案：如果有不同的資源（如預訂獲取，創建，刪除和更多），那麼我會選擇3.如果只有幾個API調用，那麼我仍然會選擇三，因爲從API的角度來看這是一個更好的表示（你的API客戶端實際上只是API的實現，所以它應該遵循API的約定，術語...至少在理論上），但是選項1可能更快起初更容易理解。如果API變得越來越複雜，那麼維護工作可能會變得很艱難，所以即使最終您也必須將其重寫爲選項3.

配置的Guzzle實例將轉到您的類的構造函數。

如果您擁有資源/服務類（在此情況下，它不會超過您的資源類的配置入口點和工廠），仍然可以擁有API客戶端類。

如果您打算重新使用該客戶端在多個項目中，你可能要考慮使用，而不是暴食的HTTP客戶端的抽象（如HTTPlug，因爲你可能無法在所有這些安裝狂飲6（依賴性的衝突，等等）

最後，但並非最不重要的，你可能要檢查this出這將是整整這些情況下，API基礎/引導（但它尚未完成，所以需要您自擔風險使用它）