API: REST o RESTful
JUAN CARLOS CONDE RAMÍREZ
WEB-SERVICES
API: ¿Qué? y ´¿Por qué?
•Si estás construyendo apps o sitios Web, es probable que ya hayas oído hablar de APIs REST o incluso ya hasta las hayas utilizado, pero probablemente no estás seguro de qué es, si debes usarlas o por donde comenzar.
•Se sabe que el termino API significa “Interfaz de Programación de Aplicaciones”. Pero en el mundo del desarrollo Web el término “API” es sinónimo de servicios Web, los cuales son utilizados por aplicaciones cliente que recuperan o actualizan datos.
•Estos servicios en línea han tenido varios nombres y formatos a lo largo de los años, tal como SOAP, sin embargo actualmente la opción más popular es usar APIs tipo REST (ó RESTful).
Lógica de negocio embebida, I
•Considera una aplicación moderna la cual pude incluir varias aplicaciones móviles ejecutables sobre diferentes plataformas y usualmente algún tipo de aplicación Web también.
•Sin un API, una arquitectura básica podría lucir como la siguiente, donde cada aplicación cliente tiene su propia lógica de negocio embebida.
Lógica de negocio embebida, II
•Nótese que cada lógica de negocio reside en cada una de las aplicaciones cliente y puede estar escrita en diferentes lenguajes, que a su vez se conectan directamente con una base de datos para obtener, actualizar o manipular datos.
•Esta lógica de negocio local muestra que cada aplicación cliente puede volverse compleja fácilmente ya que deben mantenerse sincronizadas mutuamente, es decir, cuando se requiera agregar una nueva característica, cada aplicación tendrá que ser actualizada.
•Esto puede ser un proceso muy costoso que a menudo conduce a la fragmentación de características, bugs y puede frenar la innovación.
Lógica de negocio centralizada, I
•Ahora considera la misma arquitectura con un API central, el cual es responsable de toda la lógica de negocio.
•Cada aplicación utiliza el mismo API para obtener, actualizar y manipular datos. Todas las aplicaciones tienen paridad de características, es decir, son uniformes.
Lógica de negocio centralizada, II
•Así cuando tú necesitas hacer algún cambio sólo tienes que hacerlo en un solo lugar (on-line) usando el principio de desarrollo de software: “No te repitas” (DRY – Don’t Repeat Yourself).
APIs de tipo REST, I
•En términos simples REST es un estándar para la “Transferencia de Estados Representacionales” que es un patrón arquitectónico para la creación de APIs que usan HTTP como protocolo subyacente de comunicación.
•REST fue concebido originalmente por Roy Fielding en su trabajo de tesis titulado “Estilos Arquitectónicos y el Diseño las Arquitecturas de Software basadas en Red”, donde en el capítulo 5 habla de REST específicamente.
•Casi cualquier dispositivo que se conecta a Internet hoy en día utiliza HTTP; protocolo base sobre el cual está construido Internet, siendo así una gran plataforma para la creación de APIs.
APIs de tipo REST, II
•HTTP es un sistema de solicitudes y respuestas; un cliente envía una solicitud a un destino final, mejor conocido como endpoint, que responde.
•El cliente y el endpoint puede ser cualquiera pero un ejemplo típico es un navegador que accede a un servidor Web o una aplicación que accede a una API.
Implementación con HTTP, I
•Recursos
◦ REST utiliza recursos direccionables para definir la estructura del API. Estos son URLs como las que utilizas para acceder a páginas Web, por ejemplo un recurso es “http://www.microsoft.com/Surface-Pro-3”.
•Verbos de Solicitud
◦ Estos describen lo que tú quieres hacer con el recurso. Un navegador comúnmente utiliza un verbo GET para indicarle al endpoint que necesita obtener datos, sin embargo existen otros varios verbos disponibles tales como POST, PUT y DELETE. Puedes consultar la lista completa en:
https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
•Encabezados de Solicitud
◦ Estos son instrucciones adicionales que son enviadas junto con la solicitud. Esto puede definir qué tipo de respuesta es requerida o incluso detalles de autorización. Puedes consultar la lista completa en:
Implementación con HTTP, II
•Cuerpo de la Solicitud
◦ Son los datos que son enviados en la solicitud. Por ejemplo un POST (creación de un nuevo elemento o item) requerirá algunos datos enviados típicamente como el formato de la solicitud enviada (XML o JSON).
•Cuerpo de la Respuesta
◦ Es la parte principal de la respuesta. Si la solicitud fue hecha a un servidor Web, probablemente esta será una página HTML completa, si fue hecha a una API, posiblemente sea un documento JSON o XML.
•Códigos de Estatus de la Respuesta
◦ Estos códigos describen los posibles problemas con las respuestas y proporcionan al cliente los detalles del estatus de la solicitud. La lista completa la puedes consultar en:
Relación Recurso-Verbo, I
•En el contexto de una API tipo REST, los recursos representan típicamente datos de entidades (i.e. “Producto”, “Persona”, “Orden”, etc.).
•El verbo que es enviado en la solicitud informa al API qué hacer con el recurso.
•Por ejemplo:
◦ Una solicitud GET obtendría datos acerca de una entidad, pero una solicitud POST crearía una nueva entidad.
Relación Recurso-Verbo, II
•En una convención vigente GET solicita una entidad a través de una URL, por ejemplo
/Productos, y esta devuelve una lista de productos quizás coincidentes con algunos criterios enviados con la solicitud.
•Sin embargo, para recuperar un producto específico, se podría usar su ID de producto como parte del recurso. Por ejemplo: /Productos/81 retornaría al producto con ID igual a 81.
•Con un API también es posible usar una cadena de parámetros de consulta, por ejemplo se puede tener algo como /Productos?Colo=rojo lo cual retornaría una lista de todos los productos de color rojo.
Relación Recurso-Verbo, III
•A continuación, algunas solicitudes típicas que podrías esperar utilizar con una API de comercio electrónico (ecommerce):
Recurso Verbo Resultado Esperado Código de Respuesta /Productos GET Una lista de productos del sistema 200/OK
/Productos?Color=rojo GET Una lista de productos del sistema donde el color es rojo 200/OK
/Productos POST Creación de un nuevo producto 201/Created
/Productos/81 GET Producto con ID 81 200/OK
/Productos/881
(donde el ID no existe) GET Algún mensaje de error 404/Not Found /Productos/81 PUT Una actualización del producto con ID 81 204/No Content
Arquitectura RESTful, I
•Una aplicación o arquitectura de estilo REST considera varias de las siguientes cinco características.
•En la medida en que se cumpla con todas las características, dicha aplicación o arquitectura podrá ser referida como de tipo RESTful.
•Estas características también pueden ser vistas como principios de diseño, los cuales necesitan ser seguidos cuando se trabaja con servicios basados con una arquitectura RESTful.
Arquitectura RESTful, II
1. Cliente-Servidor RESTful
•Este es el requerimiento fundamental de una arquitectura REST. Significa que el servidor tendrá un servicio Web RESTful el cual proveerá la funcionalidad requerida a uno o varios clientes.
•El cliente envía una solicitud al servicio Web ubicado en el servidor, por lo que el servidor rechazará o aceptará (y cumplirá) con la solicitud proporcionando una respuesta adecuada al cliente.
Arquitectura RESTful, III
2. Pérdida de Estado
•El concepto de Stateless (sin estado) significa que depende del cliente garantizar que toda la información requerida para una transacción sea proporcionada al servidor.
•El servidor no debe mantener ninguna búsqueda o información entre solicitud y solicitud del cliente.
•Se trata de una simple secuencia pregunta-respuesta, independiente una de otra. Cuando el cliente realiza una “pregunta”, el servidor responde apropiadamente, pero no recuerda el escenario anterior (pregunta-respuesta); para esto se necesitaría hacerse una nueva pregunta
Arquitectura RESTful, IV
•Por ejemplo:
◦ Si borras un recurso en el servidor usando el comando DELETE, no esperes que la información borrada pase a la siguiente solicitud.
◦ En este caso particular, con el fin de asegurarte que la información fue borrada, necesitarías hacer una solicitud GET para obtener todos los recursos en el servidor y ver si el recurso fue eliminado.
Arquitectura RESTful, V
3. Caché
•El concepto de Cache tiene la función de ayudar con el problema de la perdida de estado (stateless) descrito anteriormente.
•Dado que cada solicitud cliente-servidor es independiente por naturaleza, muchas veces el cliente tendrá que realizar la misma solicitud al servidor.
•Esto incrementa el tráfico en la red, por lo que el concepto de cache se maneja del lado del cliente para almacenar solicitudes que ya hayan sido enviadas al servidor.
Arquitectura RESTful, VI
•Así que si el cliente realiza la misma solicitud, en lugar de obtener la respuesta del servidor, irá a la caché y obtendrá la información requerida.
Arquitectura RESTful, VII
4. Sistema de Capas
•El concepto de sistema de capas se refiere a cualquier capa adicional, tal como una capa de
middleware, que sea insertada entre el cliente y el servidor real que aloja el servicio web
RESTFul.
•Debe recordarse que muchas veces la capa de middleware es en donde se crea toda la lógica de negocio.
•Este puede ser un servicio adicional con el cual el cliente podría interactuar antes de hacer una llamada al servicio Web principal. Pero la inclusión de esta capa debe ser transparente para que
Arquitectura RESTful, VIII
5. Interfaz/Contrato Uniforme
•Esta es la técnica subyacente que define cómo deben trabajar los servicios Web RESTful. Básicamente se trabaja sobre la capa del protocolo HTTP utilizando los siguientes verbos con su respectivo propósito, para trabajar con los recursos ubicados en el servidor.
• POST – para crear un recurso en el servidor.
• GET – para obtener un recurso desde el servidor.
• PUT – para cambiar el estado de un recurso o para actualizarlo.
