Obtener datos de una API

En el artículo anterior hemos empezado a aprender la forma de conectar nuestra aplicación Angular con API’s externas, y enviar datos que serán persistidos en una base de datos. Sin embargo, hay puntos que aún no conocemos. Por una parte, para simplificar, hemos omitido algunas cuestiones, como el hecho de que, tras grabar un nuevo socio, debemos releer la lista de socios, para mostrarla actualizada en pantalla. Por otro lado, hay formas de conectar con la API no sólo mediante el método POST, sino también, por ejemplo, mediante GET.

En este artículo vamos a seguir profundizando y aprendiendo, para poder crear un CRUD completo. Veremos como leer la lista de socios registrados, y lograr que se renderice en el navegador.

Además, veremos como se pueden relacionar unos métodos con otros, para lograr la funcionalidad deseada. Después de todo, cuando se trata de crear una aplicación, lo primero que tenemos que tener claro es qué es lo que queremos hacer, y cual debe ser la experiencia del usuario. Es cierto que en este CRUD en concreto la experiencia del usuario es bastante mejorable. Eso es porque nos estamos centrando más en conocer la operativa. Más adelante, en este curso, haremos aplicaciones más elaboradas, pero las bases programáticas serán las mismas.

LEER LOS REGISTROS

Durante el ciclo de vida de nuestro CRUD es importante poder leer los registros, tanto al inicio del módulo como durante el ciclo de vida del mismo, a fin de que el componente responsable de mostrar los registros en pantalla (MembersListComponent) pueda ofrecer la lista actualizada. Por ejemplo, al final del constructor encontramos la siguiente línea:

this.readRecords();

Como ves, se invoca a un método de usuario encargado de leer los registros. Su código seguro que ya te resulta familiar:

Ves que, una vez más, estamos suscribiendo un Observable que se obtiene en «alguna parte». Ese «alguna parte», en este ejemplo, es el método readRecord$(), cuyo listado es el siguiente:

Como puedes ver, se parece mucho a lo que ya hemos visto en el artículo anterior para grabar registros. Sin embargo, aquí hay algunas diferencias, que vamos a comentar.

En primer lugar, el método readRecord$() no recibe ningún argumento. Como vamos a leer toda la lista de miembros, no necesitamos pasarle a la API ningún argumento específico, por lo que tampoco necesitamos que el método lo reciba.

Lo siguiente que nos llama la atención es el modificador de tipo de la respuesta Observable. En este caso ya no es <any>. Ahora sabemos claramente lo que esperamos obtener de la API: una matriz de objetos con la estructura de la clase Member. Así pues, el módificador de tipo es <Member[]>.

Dentro del cuerpo del método, y usando el objeto http que creamos en el constructor a partir de la clase HttpClient, recurrimos, en esta ocasión, al método get, ya que vamos a llamar a una API cuya finalidad primaria es devolvernos «algo». El método get debe incorporar el mismo modificador de tipo que hemos establecido para el Observable. El modificador de tipo del método get podría omitirse si el Observable tuviera un tipo <any>, pero cuando no es así, debe coincidir. Si te paras a pensarlo, es completamente lógico. Si en la declaración del Observable estamos diciendo que el método readRecords$() debe devolver algo de un tipo concreto, está claro que get debe ser capaz de obtener de la API algo de ese tipo.

Al método get le pasamos la URL completa de la API a la que tiene que acceder para obtener el resultado deseado.

Volviendo al método readRecords() vemos que el método subscribe(), cuando todo se ha ejecutado correctamente, llama al método readSuccess():

Como ves, este método recibe el resultado de haber «abierto» el Observable, y lo almacena en la matriz de usuarios que MembersListComponent envía al navegador.

ATENCIÓN. Vemos que el argumento membersList que recibe el método saveSuccess() es directamente asignado a la matriz de objetos de la clase Member que luego será enviada al navegador. Un error muy común al principio es pensar que este método recibe un objeto JSON y debemos parsearlo previamente. Algo así:

this.UsersArray = JSON.parse(membersList);

Esto no sólo no es necesario, si no que, además, daría un error en tiempo de ejecución. Aunque la API devuelva un objeto JSON, como le hemos dicho al Observable que esperamos una matriz de objetos de la clase Member, Angular ya ha hecho el parseado de forma transparente, por lo que no debemos volver a hacerlo. Es el CLI de Angular quien se ha encargado de que en el método de destino recibamos los datos en el formato esperado.

OTROS MÉTODOS

En nuestro CRUD hemos visto como grabar un nuevo registro, y como leer todos los registros. Nuestro CRUD incorpora, además, otros dos conjuntos de métodos para editar un registro o borrarlo, así como otros métodos menores complementarios, que ya conocemos, para msotrar al usuario el resultado de la última operación realizada. No vamos a detenernos en estos métodos, porque, en realidad, son más de lo mismo, de lo que ya hemos visto, por lo que siguiendo el código de la aplicación, con sus comentarios, y los textos de los tres últimos artículos, no tienes ningún problema para ver toda la operativa.

LAS API’s

Las API’s para este proyecto las hemos escrito en PHP plano, de una forma muy artesanal, por dos razones. La primera es que el objetivo era centrarnos en la operativa de la aplicación Angular, no en el backend. Por otro lado, si quieres ver cómo funcionan, y como reciben o devuelven sus datos, es más cómodo así y, total, son códigos extremadamente simples, que cualquiera, con un mínimo conocimiento de PHP puede ver de un plumazo. En una aplicación real, nuestra aplicación Angular titraría contra API’s creadas en con algún framework de backend, tipo Symfony, Codeigniter, Laravel, etc.

CONCLUYENDO

Ahora sí. Te dejo la aplicación completa en este enlace, en su estado actual, para que puedas analizarla, probarla y comprobar la operativa de todo lo que hemos comentado en los tres últimos artículos. En la descarga tienes también la estructura de la base de datos MySQL y, por supuesto, las cuatro API’s en PHP. A partir del próximo artículo seguiremos mejorando nuestro CRUD para ampliar funcionalidades y, por supuesto (lo más importante), conocimientos.

   

Deja un comentario