En el artículo anterior te hablé de una capa que se encuentra externa a nuestro dispositivo móvil pero con la cual tenemos que interactuar constantemente, ¿ya recordaste cuál? El Web Server, quien en su interior tiene albergado un software que se encarga de gestionar tus solicitudes y devolverte la información que necesitas en un formato adecuado.
Hoy quiero hablarte de ese software que vive dentro del Web Server y mostrarte cómo está construido para que entendamos el papel que juega en la comunicación de nuestro dispositivo con los datos almacenados. Este software es también conocido como un Backend, que puede estar construido en diversidad de lenguajes que para quienes trabajamos del lado de la aplicación podríamos ni siquiera enterarnos de cuáles son, y siendo: Python, Ruby, JavaScript, Java, algunos de los más populares.
Para que nosotros como desarrolladores móviles podamos entender y comunicarnos con este software Backend necesitamos estar de acuerdo con el desarrollador en las reglas que debe tener para poder leer/insertar/actualizar/eliminar un registro y nos dé una respuesta de vuelta. Bueno, te cuento que a veces no tendremos la oportunidad de hablar con el desarrollador, es más, a veces ni si quiera podrás conocerlo de ninguna forma, pero aún así necesitas entender cómo funciona el software que procesará tus solicitudes.
La única forma de lograr un standard en la comunicación con el backend es implementar cierta arquitectura o diseño que sea homogénea y persistente todo el tiempo. Precisamente esto se logra con un ++API REST++, es un tipo de arquitectura de desarrollo web que significa Representational State Transfer y quiere decir que tendremos una transferencia de datos representada por un estado en particular que aplicará siempre. Es decir siempre que queramos ejecutar un tipo específico de solicitud (leer/insertar/actualizar/eliminar un registro) esta siempre será representada por un estado. Pero para completar el concepto API Rest nos falta definir ++API++; un API será un conjunto de métodos o acciones que se enfocan en un objeto en particular, por ejemplo, si analizamos todas las acciones que podemos ejecutar al objeto profesor, podrían ser:
- Leer un profesor
- Insertar un profesor
- Actualizar uprofesor
- Eliminar un profesor
A este conjunto de acciones que afectan a un objeto en particular se les llama API y como ves esta basado en POO (Programación Orientada a Objetos), y todas estas acciones se pueden aplicar a cualquier objeto.
Si unimos todo lo que acabamos de aprender, un ++API Rest++ significará un conjunto de métodos/acciones que se pueden aplicar a un objeto representadas por un estado en particular.
¿A qué tipo de estados particulares me refiero y cómo los puedo representar? Bueno precisamente esta es la parte donde te hablo de los ++verbos HTTP++, los verbos son las acciones que puede tener el objeto pero tienen que ser representadas por algo que el protocolo HTTP entienda, por ejemplo: si queremos leer un profesor el verbo HTTP será GET, mira los demás:
- Leer un profesor GET
- Insertar un profesor POST
- Actualizar un profesor PUT(antes) / PATCH(ahora)
- Eliminar un profesor (DELETE)
Probablemente solo habías escuchado del método GET y POST pues son los más comunes, pero los demás realmente existen.
Entonces, el estándar de comunicación que debe tener el software backend debe ser idealmente un API Rest, para que aunque no tengamos el gusto de conocer al programador sabremos que cumplirá las siguientes reglas:
-
La base de las acciones serán siempre objetos.
-
Siempre tendremos un API definido para cualquier objeto o sea insertar/leer/actualizar/eliminar en inglés sería Create/Read/Update/Delete seguramente has visto algo como CRUD.
-
Las acciones serán definidas por un estado o un verbo HTTP (POST/GET/PATCH/DELETE).
Por lo tanto siguiendo estas reglas si nos concentramos en el objeto profesores, yo podré ejecutar las siguientes acciones con esta url base ++https://platzi.com/profesores++ (Los enlaces de acontinuación son usados solo para ejemplificar)
Donde cada url de este tipo en conjunto con su método se llamará ++Endpoint++.
Esto que te acabo de mostrar son tan solo ejemplos básicos que nos ayudan a entender más todos estos conceptos, en general todas las API’s deben trabajar con estos puntos que platicamos, si quieres saber más sobre APIs Rest te recomiendo leer este artículo que se encuentra en el blog de Platzi.
Quiero que entres a este enlace que habla sobre el API de Medium, aprende todo sobre ella e identifica todos los elementos que acabamos de platicar, cuentame aquí en los comentarios lo que aprendiste del API de Medium.
En los siguientes artículos te enseñaremos a implementar esta API en tus aplicaciones Android con Retrofit.
