Hice un proyecto basado en Symfony que usa una API externa (JSON); lo que hice fue crear una biblioteca cliente independiente ("biblioteca cliente" - una pieza de software, paquete compositor), con su propio conjunto de entidades (POPO); se integra con el marco utilizando interfaces proporcionadas por Symfony (por ejemplo, simplemente creando un proveedor de usuario personalizado ).
El cliente realiza llamadas http "detrás de escena", lo cual es importante para futuras capacidades de prueba. No desea exponer la forma en que se comunica con su fuente de datos y tampoco desea que sus pruebas dependan de la API en vivo.
Interfaz de la biblioteca del cliente (ejemplo, cómo puede verse):
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 biblioteca del cliente utiliza internamente Guzzle para la comunicación y el componente Doctrine Cache para almacenar en caché los resultados. El mapeo entre objetos de entidad y json fue realizado por mapeadores, que una vez escritos, no cambiaron muy a menudo (o evento en absoluto). En este caso, sugeriría usar el serializador JMS para una transformación automática hacia y desde JSON (supongo que usa JSON).
Necesitará un buen mecanismo de almacenamiento en caché y almacenamiento local, como Redis. Hacer llamadas de API en cada solicitud de aplicación matará a su servidor y ralentizará drásticamente su aplicación. Es muy importante entender cómo funcionan los cachés http. Si su API no usa encabezados de almacenamiento en caché (o los usa de una manera oscura), será muy difícil y consumirá muchos recursos realizar un seguimiento de los cambios.
También querrá pensar en cómo debería comportarse el cliente si se corta la conexión. ¿Debería el cliente usar datos estancados? Sería una buena idea utilizar algún servidor proxy entre su aplicación y la API. En este caso, el proxy (como Varnish) podría acelerar sus solicitudes y también actualizar los datos detenidos en segundo plano sin ralentizar su aplicación. También mantendrá su sitio web en línea en caso de falla de la API. Es posible que no pueda escribir datos mientras tanto, pero sus usuarios aún podrán examinar los datos almacenados en caché.
Y hablando de Doctrina, vea la " Ley del instrumento ".