Ho realizzato un progetto basato su symfony che usa un'API esterna (JSON); quello che ho fatto è stato creare una libreria client indipendente ("client library" - una parte di software, pacchetto di compositore), con il proprio set di entità (POPO); si integra con il framework utilizzando le interfacce fornite da Symfony (ad esempio, creando semplicemente un provider utente personalizzato ) .
Il client effettua chiamate http "dietro le quinte" - questo è importante per le funzionalità di test future. Non vuoi esporre il tuo modo di comunicare con la tua fonte di dati e inoltre non vuoi che i tuoi test facciano affidamento su live API.
Interfaccia della libreria client (ad esempio come potrebbe essere):
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);
}
La libreria client utilizza internamente Guzzle per la comunicazione e il componente Doctrine Cache per il caching dei risultati. La mappatura tra oggetti entità e json è stata effettuata dai mappatori, che una volta scritti non sono cambiati molto spesso (o eventi). In questo caso, suggerirei di usare JMS Serializer per una trasformazione automatica da e verso JSON (presumo che tu usi JSON).
Avrai bisogno di un buon meccanismo di memorizzazione nella cache e di una memoria locale, come Redis. Effettuare chiamate API su ogni richiesta di app ucciderà il server e rallenterà drasticamente l'applicazione. È molto importante capire come funzionano le cache http. Se la tua API non usa le intestazioni di cache (o la usa in modo oscuro) sarà molto difficile e dispendioso in termini di risorse per tenere traccia delle modifiche.
Dovresti anche pensare a come dovrebbe comportarsi il client se la connessione si interrompe, se il client usa dati in stallo? Sarebbe una buona idea utilizzare un server proxy tra la tua app e l'API. In questo caso il proxy (come Varnish) potrebbe velocizzare le tue richieste e anche aggiornare i dati in stallo in background senza rallentare la tua app. Mantiene anche il tuo sito Web online in caso di errore API. Potresti non essere in grado di scrivere dati nel frattempo, ma i tuoi utenti potranno comunque consultare i dati memorizzati nella cache.
E a proposito di Doctrine, consulta la " Legge dello strumento ".