conceptosRest
- Conceptos Básicos de REST
- Diseño API REST
- Implementación API REST con Spring
- Tutorial Ejemplo básico implementación API
- Tutorial Completo Book implementación API
- Creación de pruebas postman
REST es un estilo arquitectural para sistemas distribuidos hipermedia. Permite describir la arquitectura de la Web como un gran sistema distribuido hipermedia. Su característica principal es que define una interfaz uniforme entre los componentes del sistema: cada componente de la Web (pensemos en cualquier cosa que se puede acceder por internet) se pueden comunicar de la misma forma con cualquier otro componente, no importa cuáles sean los servicios que cada componente ofrece ni quién lo haya desarrollado. El protocolo y la forma en que se definen los servicios es la misma.
El protocolo más utilizado para implementar esta arquitectura es HTTP (Hypertext Transfer Protocol).
Sin embargo, la arquitectura REST no es solo el protocolo, también incluye la forma como entendemos los componentes de la Web.
Cada componente se define en términos de los recursos que maneja y no de los servicios que ofrece.
Por ejemplo, si pensamos en algo como Spotify, como componente de la Web, identificamos que los recursos que manipula son canciones, discos, artistas. Si nuestro ejemplo fuera banner, los recursos serían estudiante, profesor, curso, etc.
Los componentes que conforman el sistema (la Web) manejan recursos. Cada recurso tiene una manera única de identificarlo (su URI), tiene una o más representaciones y le pertenece a alguien. Los recursos pueden ser una página Web, un video, un sonido, una animación, un objeto JSON, un xml, etc.
URI: "Uniform Resource Identifiers" (URIs) sirve para identificar de manera única un recurso de la red. Una URI contiene una URL (Uniform Resource Locator) para localizar el recurso y un nombre URN (Uniform Resource Name).
La sintaxis genérica de un URI sigue la siguiente forma:
scheme:[//[user:password@]host[:port]][/]path[?query][#fragment]
Ejemplos de esto son:
Ejemploshttp://www.yourserver.com/logo.gif
En este caso:
-
http es el
schema -
www.yourserver.com es el
host -
logo.gif es el
path(el nombre del recurso)
http://www.google.com/search?q=low
En este caso:
-
http es el
schema -
www.google.com es el
host -
search es el
path -
q=low es el
query
Una descripción más detallada sobre el formato de las URIs puede ser encontrada aquí: Formato de las URIs
Podemos definir/diseñar distintas formas para representar un recurso. Los recursos son más que páginas, imágenes o videos, también representan información que maneja la aplicación, por ejemplo: los empleados de una compañía, los estudiantes de una universidad. Para representar estos recursos existen varios formatos estándar como por ejemplo: XML o JSON, siendo JSON el más popular.
Si quisiéramos representar un recurso empleado, en alguna aplicación de una compañía, utilizando JSON podemos definir:
Un recurso empleados:
{"empleados":[
{"nombre":"Juan", "apellido":"Perez"},
{"nombre":"Ana", "apellido":"Gutierrez"},
{"nombre":"Pedro", "apellido":"Ruiz"}
]}El recurso contiene un conjunto de empleados, donde cada empleado tiene un _nombre _y un _apellido _
Este mismo ejemplo en formato XML:
<empleados>
<empleado>
<nombre>Juan</nombre> <apellido>Pérez</apellido>
</empleado>
<empleado>
<nombre>Ana</nombre> <apellido>Gutierrez</apellido>
</empleado>
<empleado>
<nombre>Pedro</nombre> <apellido>Ruiz</apellido>
</empleado>
</empleados>En los ejemplos anteriores, la decisión de diseño fue definir que un empleado se representa por el nombre y el apellido. Lo demás es el formato que podemos utilizar para representarlo, en el primer caso JSON y en el segundo XML. Note que en ambos casos, está el nombre del atributo del empleado y el valor.
En esta arquitectura, sin importar cuál sea el recurso, las operaciones que se pueden hacer sobre ellos son siempre las mismas. Básicamente estas son: Obtenerlo (GET), crearlo (POST), borrarlo (DELETE), actualizarlo (PUT).
El protocolo HTTP es una forma de implementar la arquitectura REST; este protocolo define los verbos que indican la acción que se efectúa sobre el recurso. Los más importantes son GET, POST, PUT, DELETE que leen, crean, modifican o borran un recurso. Por ejemplo, si en un navegador escribimos la siguiente URL:
www.mislibros.com/elmasvendido.pdf
El navegador localiza el recurso en la dirección www.mislibros.com y su petición es un GET. El componente que se está ejecutando en la dirección www.mislibros.com entiende la petición GET y devuelve el recurso llamado elmasvendido.pdf (en representación pdf) o, si no lo encuentra, un error HTTP 404 not found.Cuando el navegador recibe la respuesta, ya sea el recurso o el error, se lo muestra al cliente quien lo solicitó.
La sigla REST significa: REST: Representational State Transfer. Expliquemos con un ejemplo: cuando una aplicación, app1, hace una petición REST a otra aplicación, app2, con esa petición viaja toda la información que se requiere para que app2 la responda. Decimos que viaja o que se transfiere el estado. Si por ejemplo, app2 necesita las credenciales de autenticación de quien está haciendo la petición, estas deben viajar con la petición. La aplicación app2 no guarda el estado de quien está interactuando con ella, en nuestro ejemplo, no guarda las credenciales de app1. Si la misma _app1 _ hace otra petición, debe enviar de nuevo dichas credenciales. Esta característica permite que las aplicaciones escalen fácilmente porque las aplicaciones no necesitan mantener conexiones por largo tiempo y se pueden reutilizar.
Aunque Roy Fielding acuñó el término REST en su tesis doctoral en el año 2000 es solo desde hace unos pocos años que esta arquitectura se ha popularizado. Una de las razones, a parte de su simplicidad, está en el significado de la sigla "Representational State Transfer". Decimos que una aplicación es Restful si ofrece un API siguiendo las convenciones de la arquitectura REST: utiliza HTTP de acuerdo con la semántica definida de los verbos, tiene una definición clara de sus recursos , tanto de su identificación como de sus representaciones, y no mantiene un estado con los clientes.
