¿Qué es un REST API?

Ya hablamos acerca de los WEB Apis, ahora vamos a hablar acerca de un estilo de cómo hacer web apis: Rest.

Rest, que significa Representational State Transfer es un estilo de construir servicios web los cuales se adhieren a un conjunto de principios establecidos. Entonces, la idea aquí es que hay un conjunto de condiciones que un web api debe de tener para poder decir que implementa Rest. Cuando un web api respeta estas condiciones, a dicho web api le llamamos restful.

Normalmente, cuando consumimos un web api, es porque queremos acceder a sus recursos. En nuestro contexto, un recurso hace referencia a cosas o entidades que puedes consumir de un web api. Por ejemplo, si tenemos un web api que nos permite trabajar con el sistema de una biblioteca, un recurso que el web api podría exponer sería el listado de libros de la biblioteca. Otro recurso que el web api podría exponer sería el listado de empleados de la biblioteca.

Una idea que se relaciona con rest es la de utilizar “verbos HTTP sobre una URL para ejecutar distintas funciones del Web API. Por ejemplo, supongamos que tenemos la url: https://miWebApi.com/api/User, y sobre esta hacemos un HTTP Get, entonces obtenemos un listado de los usuarios, y si hacemos un HTTP Post a esta misma URL, donde enviamos la información de un usuario, entonces vamos a ejecutar la funcionalidad de crear un usuario en nuestro servidor. A esto le llamamos HTTP CRUD, porque podemos crear, leer, actualizar y borrar información consumiendo un web api utilizando HTTP, sin embargo, esto no es suficiente para decir que un web api es restful. En la siguiente entrada hablaremos acerca de los verbos HTTP, por ahora, concentrémonos en las condiciones que hacen que un web api sea restful.

La ventaja de respetar estas condiciones es que, en general, tenemos beneficios añadidos, como un software que puede desarrollarse y responder a cambios de requerimientos de negocio de una manera eficiente. Es importante destacar, que no todos los web apis que hagas tienen que ser restful, al final, rest es solo una guía para desarrollar web apis, la cual no tienes que seguir al pie de la letra para que tu web api sea “bueno”.

Como ya dijimos, para que un Web API sea restful, debe respetar las 6 condiciones de Rest. Vamos entonces a hablar de estas seis condiciones:

1) Arquitectura cliente-servidor

La arquitectura cliente servidor nos habla de la separación entre un cliente y un proveedor o servidor. En el caso de los web apis, el servidor es un servidor web; el cliente puede ser cualquier software capaz de comunicarse utilizando HTTP con el servidor web. Por ejemplo, una página web en un navegador, una aplicación en un celular, e incluso una aplicación de escritorio. Con este principio, aseguramos la separación de responsabilidades entre nuestro servicio de web api y los clientes que consumen dicho servicio. Así, nuestro web api puede evolucionar en el servidor, y eso no necesariamente debe de afectar a los clientes de nuestro servicio.

2) Interfaz uniforme

La idea de la interfaz uniforme es tener una forma estandarizada de transmisión de información. Con esta condición, tenemos una manera “universal” de utilizar web apis comunes. La idea entonces es que, si sabes consumir un web api, sepas consumir otros web apis sin mucha dificultad. La condición de interfaz uniforme nos pide 4 sub-condiciones:

Identificación de recurso: Utilizamos URL’s para identificar recursos. Así, podemos utilizar la URL: https://miApi.com/api/libros para acceder al listado de libros de nuestro web api, suponiendo que nuestro web api expone dicho recurso.

Manipulación de recursos usando representaciones: La idea aquí es que si el cliente tiene una manera para acceder al recurso, típicamente una URL, entonces ya con esto puede modificar el recurso. En nuestro caso, utilizaremos verbos HTTP para esto. Más información de esto en la próxima entrada.

Mensajes autodescriptivos: Todos los mensajes son completos, en el sentido de que indican toda la información necesaria para que sean trabajados por el servidor de manera satisfactoria. Cuando hablamos de mensajes, en nuestro caso nos referimos a peticiones HTTP que hacemos al servidor. Algo que un mensaje puede indicar es el formato en el que quiere la información del servidor, para eso podemos utilizar media types. Los media types son identificadores de formato que utilizamos para indicar de qué manera queremos que se nos de la información. Por ejemplo, podemos pedir que la información del web api se nos dé en formato json, formato XML, formato pdf, etc. Claro, es importante destacar que, aunque el cliente tiene el poder de pedir la información en el formato que desea, es responsabilidad del servidor poder satisfacer la petición del cliente. Si la petición del cliente no es razonable, el servidor no tiene por qué satisfacerla. Por ejemplo, si el cliente quiere un listado de libros del web api, y lo pide en formato jpeg, el cual es un formato de imagen, esto ni siquiera tiene sentido, por lo que nuestro web api no tiene por qué satisfacer dicha demanda. Sin embargo, sí es razonable que el cliente nos pueda pedir esta información en formato XML o JSON.

Hypermedia as the engine of application state (HATEOAS): Esto significa que la información que nos da el web api cuando hacemos una petición debe incluir links para poder seguir explorando los demás recursos del web api. Por ejemplo, si pedimos un listado de libros de nuestro web api, sería ideal que cada uno de esos libros tenga un link el cual nos permita ver el detalle de cada uno de los libros.

3) Protocolo sin estado

Cada una de las peticiones realizadas al web api tienen toda la información necesaria para que la petición sea resuelta de manera satisfactoria. Así, si nuestro web service requiere que el cliente esté debidamente identificado para acceder y manipular un recurso, entonces el cliente debe de enviarnos algún tipo de información que identifique al cliente que está haciendo la petición cada vez que se haga una petición HTTP al servidor.

4) Cache

Las respuestas del web api deben de indicar cuando se deben guardar en cache. Cuando hablamos de cache, nos referimos a que el cliente puede guardar el recurso dado por una url de manera local, en tal sentido que en subsiguientes peticiones http, dicho recurso no tenga que ser pedido al web api, sino que se pueda consumir la versión local. Esto disminuye el tiempo de respuesta que deben esperar los clientes de nuestra aplicación. No todo se debe guardar en cache, pues esto pone en riesgo a nuestros clientes de trabajar con data desactualizada.

5) Sistema de capas

El servicio del servidor debe tener una arquitectura de capas, donde su evolución sea completamente transparente para el cliente. Así por ejemplo si tu servicio web va a utilizar load balancers, tus clientes no tienen por qué tener presente este detalle, esto debe ser completamente transparente para ellos.

6) Código en demanda (opcional)

El servicio web tiene la opción de enviar código fuente el cual se va a ejecutar en el cliente. Típicamente este código es Javascript.

Conclusión

Un rest API es todo web API que siga las 6 condiciones descritas en esta entrada. No todo web API que hagas debe respetar estas condiciones, no es obligatorio hacerlo. Estas condiciones son una guía para escribir web API’s.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s