Una interfaz de programación de aplicaciones o API es una forma en que dos computadoras se comunican entre sí; usar una API es como explorar una página web en el navegador pero en lugar de hacer clic en botones y rellenar formularios de contacto, precios, iniciar sesión, etc. escribes el código en un fichero aparte para solicitar explícitamente los datos de un servidor, por ejemplo: cuando entras en Facebook y comienzas a publicar contenido y comentar fotos de tus amigos estás consumiendo la API de Facebook a través del navegador.
La mayoría de las API en el mundo son de tipo RESTFul lo que significa que siguen un conjunto de reglas o restricciones conocidas como transferencia de estado representacional, que ha sido el estándar de facto para el desarrollo de api desde principios de la década de 2000.
Una api RESTFul organiza las entidades de datos o los recursos en un montón de URL únicas, técnicamente no son URL, sino URIS o identificadores de recursos uniformes que diferencian diferentes tipos de recursos de datos en un servidor, un cliente puede obtener datos sobre un recurso haciendo una solicitud a ese endpoint.
HTTP el mensaje de solicitud y tiene un formato muy específico, lo que es más importante, la línea de inicio contiene la URI al que desea acceder, que está precedido por un verbo HTTP o un método de solicitud que indica su intención con el recurso, una solicitud de tipo GET significa que solo deseamos leer los datos mientras que POST significa que queremos crear un registro; PATCH es para actualizaciones y DELETE es para eliminar datos junto con algunos otros métodos más allá de los que están debajo de la línea de inicio.
Tenemos los HEADERS que contienen metadatos sobre la solicitud, el header ACCEPT le dice al servidor en qué formato queremos recibir los datos y el header AUTHORIZATION se puede usar para decirle al servidor que estamos autorizados para hacer esa solicitud.
Luego tenemos el BODY que contiene una carga de datos personalizados, el servidor recibirá el mensaje de solicitud y luego ejecutará un código generalmente para leer de una base de datos que se puede formatear en un mensaje de respuesta. La parte superior del mensaje contiene un código de estado para decirle al cliente lo que sucedió.
Los códigos de respuesta con nivel 200 significa que las cosas salieron bien mientras que en el nivel 400 quiere decir que algo estaba mal con la solicitud y en el nivel 500 significa que el servidor falló por alguna razón.
Después del código de respuesta de estado tenemos los encabezados de respuesta o RESPONSE que contienen información sobre el servidor, es decir, el resultado de la consulta que hemos enviado, por ejemplo un listado de clientes, proveedores, etc generalmente está formateado en JSON.
Una parte importante de esta arquitectura es que es STATELES que quiere decir que no tiene control de estados, esto significa que tanto el cliente (aquel que consume el servicio) como el servidor (el que provee los datos) no necesitan almacenar ninguna información sobre el estado de la petición o nada parecido, cada petición y ciclo de respuesta es independiente de todas las demás comunicaciones, esto conduce a aplicaciones web de buen comportamiento que son predecible y confiables.
En las siguientes entradas veremos como crear un servicio web completo para finalmente consumirlo desde el cliente que se nos antoje (móvil, web, desktop, etc) así que mantente conectado.
No hay comentarios:
Publicar un comentario