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接尾辞で指定されたクラスを扱わなければなりません。 IMO彼は要求や技術的なことについて何も知らない。

---

例3：

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

この例では一つの層を追加します。

---

すべての場合、ApiClient/ServiceクラスのGuices httpClient属性はどこですか？ ApiClientクラスはGuzz Clientクラスを拡張する必要がありますか？

Answer 1

さて、そこには実際の基準はありませんが、これは間違いなくホットな話題です。私は、Guzzle特有のものではないとも言います。

短い答え：私は、APIの複雑さに基づいてオプション1と3を選択します。

長い回答：別のリソース（取得、作成、削除などの予約など）がある場合は、オプション3を使用します。API呼び出しが少々ある場合は、 APIの観点から見ればより良い表現であるため（APIクライアントは実際にはAPIの実装にすぎないので、少なくとも理論的にはAPIの規則、用語に従うべきです）、オプション1は高速です最初は理解しやすくなりました。 APIがより複雑になるとメンテナンスが難しくなるので、最終的にはそれをオプション3に書き直す必要があります。

設定済みのGuzzleインスタンスは、クラスのコンストラクタに移動します。

リソース/サービスクラスがある場合は、引き続きAPIクライアントクラスを使用できます。この場合、リソースクラスの設定エントリポイントとファクトリを超えません。

このクライアントを複数のプロジェクトで再利用する予定がある場合は、Guzz 6をすべてインストールできない可能性があるため、HTTP Client抽象化（GuzzleではなくHTTPlugなど）を使用することを検討してください。 ）