Zrobiłem projekt oparty na symfony, który używa zewnętrznego API (JSON); to, co zrobiłem, to stworzenie niezależnej biblioteki klienta („biblioteka klienta” - oprogramowanie, pakiet kompozytora), z własnym zestawem jednostek (POPO); integruje się ze strukturą za pomocą interfejsów dostarczanych przez Symfony (na przykład, po prostu tworząc niestandardowego dostawcę użytkownika ).
Klient wykonuje połączenia HTTP „za kulisami” - jest to ważne dla przyszłych możliwości testowania. Nie chcesz ujawniać sposobu komunikacji ze źródłem danych, a także nie chcesz, aby testy opierały się na interfejsie API na żywo.
Interfejs biblioteki klienta (przykład jak może to wyglądać):
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);
}
Biblioteka klienta wewnętrznie używa Guzzle do komunikacji i komponentu Doctrine Cache do buforowania wyników. Odwzorowanie między obiektami encji a Jsonem zostało wykonane przez twórców mapowania, którzy raz napisali - nie zmieniali się bardzo często (ani wcale zdarzeń). W takim przypadku sugerowałbym użycie JMS Serializer do automatycznej transformacji do i z JSON (zakładam, że używasz JSON).
Będziesz potrzebował dobrego mechanizmu buforowania i lokalnego magazynu, takiego jak Redis. Wykonywanie api-połączeń przy każdym żądaniu aplikacji zabije serwer i drastycznie spowolni aplikację. Bardzo ważne jest, aby zrozumieć, jak działają pamięci podręczne http. Jeśli twój interfejs API nie używa buforujących nagłówków (lub używa go w niejasny sposób), śledzenie zmian będzie bardzo trudne i pochłania zasoby.
Zastanów się także, jak powinien zachowywać się klient, jeśli połączenie zostanie zerwane - czy klient powinien użyć zablokowanych danych? Dobrym pomysłem byłoby użycie serwera proxy między aplikacją a interfejsem API. W takim przypadku serwer proxy (np. Varnish) może przyspieszyć żądania, a także odświeżyć zablokowane dane w tle bez spowalniania aplikacji. Utrzyma również twoją stronę internetową w przypadku awarii interfejsu API. W międzyczasie możesz nie być w stanie zapisywać danych, ale użytkownicy nadal będą mogli przeglądać dane w pamięci podręcznej.
Mówiąc o doktrynie, patrz „ Prawo instrumentu ”.