Làm cách nào để sử dụng API RESTful bên ngoài với Symfony?

Chúng tôi đang xây dựng một kiến ​​trúc microservice cho các dự án của chúng tôi, với các ứng dụng Symfony chủ yếu ở mặt trước tương tác với các API RESTful phía sau.

Vấn đề là cách tiếp cận này đang phá vỡ sự quản lý thực thể Symfony phụ thuộc rất nhiều vào Doctrine với cơ sở dữ liệu. Trong đó Symfony thường xử lý các thực thể bằng Doctrine, tự động hóa hầu hết công việc, điều này không thể được sao chép dễ dàng khi chúng ta phải truy cập dữ liệu ngoài từ API.

Ví dụ: với thực thể Máy khách:

• Sử dụng Doctrine, chúng ta chỉ cần xác định lớp Client của mình và giờ đây thật dễ dàng để tạo, cập nhật, truy xuất ứng dụng khách của chúng ta
• Sử dụng phương pháp API REST, khách hàng có thể truy cập thông qua API, nhưng chúng tôi có rất nhiều công việc để xác định cách khách hàng được tạo (POST), cập nhật (PUT), truy xuất (GET), v.v.

Để lưu ý khách hàng được sử dụng bởi một số ứng dụng, không chỉ ứng dụng front-end, do đó là API chuyên dụng.

Chúng ta có nên tạo các lớp với các phương thức giống như thực thể che giấu sự phức tạp của các lệnh gọi API, nhập tất cả dữ liệu API cục bộ và truy cập chúng thông qua Doctrine hoặc bất kỳ cách nào khác không?

Tôi đã thực hiện một dự án dựa trên symfony đang sử dụng API bên ngoài (JSON); những gì tôi đã làm là tạo ra một thư viện máy khách độc lập ("thư viện máy khách" - một phần mềm, gói soạn thảo), với tập thực thể riêng (POPOs); nó tích hợp với khung sử dụng các giao diện do Symfony cung cấp (ví dụ: chỉ bằng cách tạo nhà cung cấp người dùng tùy chỉnh ).

Máy khách thực hiện các cuộc gọi http "hậu trường" - điều này rất quan trọng đối với các khả năng thử nghiệm trong tương lai. Bạn không muốn phơi bày cách bạn giao tiếp với nguồn dữ liệu của mình và bạn cũng không muốn các bài kiểm tra của mình dựa vào api trực tiếp.

Giao diện thư viện máy khách (ví dụ như giao diện của nó):

class ApiClient {

   /**
    * @throws SomeApiException If credentials are invalid
    * @return ApiUser
    */
   public function authenticate($username, $password);

   /**
    * @return ApiUser
    */
   public function findUserByEmail($email);

   /**
    * @throws SomeApiException If email is invalid
    * @return void
    */
   public function changeUserEmail(User $user, $newEmail);
}

Thư viện khách bên trong sử dụng Gujection để liên lạc và thành phần Bộ đệm bộ đệm để lưu kết quả. Ánh xạ giữa các đối tượng thực thể và json được tạo bởi những người lập bản đồ, một khi đã được viết - không thay đổi rất thường xuyên (hoặc sự kiện nào cả). Trong trường hợp này, tôi sẽ đề nghị sử dụng Trình tuần tự JMS để chuyển đổi tự động sang và từ JSON (Tôi giả sử rằng bạn sử dụng JSON).

Bạn sẽ cần một cơ chế lưu trữ tốt và bộ nhớ cục bộ, như Redis. Thực hiện cuộc gọi api trên mỗi yêu cầu ứng dụng sẽ giết chết máy chủ của bạn và làm chậm đáng kể ứng dụng của bạn. Điều rất quan trọng để hiểu làm thế nào http cache hoạt động. Nếu api của bạn không sử dụng các tiêu đề bộ đệm (hoặc sử dụng nó theo cách tối nghĩa), sẽ rất khó khăn và tốn tài nguyên để theo dõi các thay đổi.

Bạn cũng sẽ muốn nghĩ về cách ứng xử của khách hàng nếu kết nối bị ngắt - khách hàng có nên sử dụng dữ liệu bị đình trệ không? Sẽ là một ý tưởng tốt khi sử dụng một số máy chủ proxy giữa ứng dụng của bạn và API. Trong trường hợp này, proxy (như Varnish) có thể tăng tốc các yêu cầu của bạn và cũng làm mới dữ liệu bị đình trệ trong nền mà không làm chậm ứng dụng của bạn. Nó cũng sẽ giữ cho trang web của bạn trực tuyến trong trường hợp lỗi API. Bạn có thể không thể ghi dữ liệu trong thời gian này, nhưng người dùng của bạn vẫn có thể duyệt dữ liệu được lưu trong bộ nhớ cache.

Và nói về Học thuyết, xem " Luật của công cụ ".

Học thuyết là một lớp truy cập cơ sở dữ liệu. Bạn không muốn truy cập cơ sở dữ liệu, nhưng apis. Bạn vẫn có thể tạo một Thực thể, nhưng sau đó là một đối tượng đơn giản không phải mở rộng triển khai thực hiện bất kỳ thứ gì (popo). Nó nên có một Kho lưu trữ thực hiện tất cả các phương thức CRUD. Trong trường hợp này gọi API thay vì cơ sở dữ liệu. Tôi sẽ tạo một giao diện cho điều đó. Ứng dụng của bạn không cần phải cảm thấy khác biệt, ngoại trừ việc bạn phải tính đến mọi nơi mà dịch vụ vi mô có thể không đáp ứng.

FYI, hiện đã có thành phần HttpClient cho v4.3.

https://symfony.com/blog/new-in-symfony-4-3-httpclient-component