REST VS REST
FULL
¿ QUE ES REST Y RESTFULL? (VER VIDEO)
Cada día necesitamos más usar servicios web
REST. Estos servicios se diferencian de una forma importante de los servicios
web SOAP con los que hemos estudiado. REST (Representational State Transfer) es
un estilo de arquitectura para desarrollar servicios. Cabe resaltar si la web Services HTTP, ha sido diseñada
cumpliendo estas premisas entonces se le puede llamar Servicio web HTTP RESTFULL, si no cumple con estas
restricciones entonces es un servicio HTTP REST -BASED. Los servicios web que
siguen este estilo deben cumplir con las siguientes premisas.
Sin estado: Son servicios web que no mantienen estado asociado al cliente
.Cada petición que se realiza a ellos es completamente independiente
de la siguiente. Todas las llamadas al mismo servicio serán idénticas.
Cache : El contenido de los servicios web REST ha se puede cachear de tal
forma que una vez realizada la primera petición al servicio el resto puedan
apoyarse en la cache si fuera necesario.
Servicios Uniformes: Todos los servicios REST compartirán una
forma de invocación y métodos uniforme utilizando los métodos GET,POST,PUT
,DELETE
Arquitectura en Capas: Todos los servicios REST están orientados hacia la escalabilidad y un
cliente REST no será capaz de distinguir entre si está realizando una petición
directamente al servidor, o se lo está devolviendo un sistema de caches
intermedio o por ejemplo existe un balanceador que se encarga de redirigirlo a
otro servidor.
El enfoque RESTful de los servicios web
surge como una alternativa popular por su naturaleza liviana y a la capacidad
de transmitir datos directamente sobre HTTP. Los clientes se implementan usando
una gran variedad de lenguajes como programas Java, Perl, Ruby, Python, etc.
Generalmente se accede a los servicios web RESTful a través de un cliente
automatizado o una aplicación que actúa en representación del usuario. Sin
embargo, la simplicidad de estos servicios posibilita la interacción humana
directa.
Los fundamentales principios:
- utiliza los métodos HTTP de manera explícita
- no mantiene estado
- expone URIs con forma de directorios
- transfiere XML, JavaScript Object Notation
(JSON), o ambos
Estos principios se basan en separar tu
API en recursos lógicos. Estos recursos son manipulados usando peticiones HTTP
donde el método (GET, POST, PUT, PATCH, DELETE) tienen un significado
específico. ¿Pero qué puede hacer un recurso?
Bueno, estos deberían ser sustantivos (¡no
verbos!) Que tengan sentido desde una perspectiva del
consumidor de la API. Por ejemplo, algunos de los sustantivos de SupportFu
podrían ser usuario y clave.
Una vez que tienes tus recursos definidos, necesitas identificar qué
acciones aplican a ellos y cómo deberían relacionarse con tu API. Los
principios REST proveen estrategias para manejar acciones CRUD usando
métodos HTTP relacionados de la siguiente forma:
- GET / usuario - Devuelve una lista de usuario
- POST / usuario - Crea un nuevo usuario
- PUT / usuario /12- Actualiza el usuario #12
- DELETE / usuario /12- Elimina el usuario #12
Características
- REST presenta los servicios como
recursos, que pueden ser consumidos a través de la web.
- REST no se considera un estándar por
sí mismo más bien está basado en estándares: http, URL, XML/HTML/PNG/etc.
-REST basa sus accesos a servicios web
en la sintaxis de una URL. Ejemplo http://www.dominio.com/clientes/obtenernombres
- La simplicidad es la base de REST, el
beneficio de esta simplicidad está basado conseguir un buen rendimiento y
eficiencia, el mensaje transmitido por lo mismo de su simplicidad es bastante
ligero, pero al ser el mensaje más sencillo carece de estándares de seguridad y
cifrado
Implementación
así pues, teniendo claros estos conceptos y cómo se relacionan con el
protocolo HTTP, y sabiendo que un servicio web RESTful hace referencia a un
servicio web que implementa la arquitectura REST, podemos ya dar una definición
concisa, lo cual nos dejará claro cómo tenemos que implementarlo en nuestras
aplicaciones. Un servicio web RESTful contiene lo siguiente:
- URI del recurso. Por
ejemplo: http://api.servicio.com/recursos/persna/1 (esto nos daría acceso
al recurso “Persona” con el ID “1”)
- El tipo de la representación
de dicho recurso. Por ejemplo, podemos devolver en nuestra cabecera
“Content-type: application/json”, por lo que el cliente sabrá que el
contenido de la respuesta es una cadena en formato JSON, y podrá
procesarla como prefiera. El tipo es arbitrario, siendo los más comunes JSON,
XML y TXT.
- Operaciones soportadas: HTTP
define varios tipos de operaciones (verbos), que pueden ser GET, PUT,
POST, DELETE, PURGE, entre otros. Es importante saber para qué están
pensados cada verbo, de modo que sean utilizados correctamente por los clientes.
- Hipervínculos: por último,
nuestra respuesta puede incluir hipervínculos hacia otras acciones que
podamos realizar sobre los recursos. Normalmente se incluyen en el mismo
contenido de la respuesta, así si por ejemplo, nuestra respuesta es un
objeto en JSON, podemos añadir una propiedad más con los hipervínculos a
las acciones que admite el objeto.
Bibliografia
https://www.youtube.com/watch?v=oRhyn45o3qE
https://www.youtube.com/watch?v=gKBiIWY7FYw&list=PLu47tUtKqNlwfR-nqjiWUaIWOYEi9FyW0
https://www.youtube.com/watch?v=xkKcdK1u95s&list=PLqq-6Pq4lTTZh5U8RbdXq0WaYvZBz2rbn
http://www.adwe.es/general/colaboraciones/servicios-web-restful-con-http-parte-i-introduccion-y-bases-teoricas
