Nombre: Eduardo Lastra Galeana

Matrcula: 10301390
Nombre de la materia:
Nombre del profesor:

Servicios Web

Jos Ney Garrido Vzquez

Unidad V

Actividad:
Reporte de Investigacin (REST y
Servicios WEB relacionados).

Fecha: 26 /05 /15

Bibliografa:

C, lvarez. (2013). Introduccin a Servicios REST. Arquitectura Java.

Recuperado de http://www.arquitecturajava.com/servicios-rest/

(2015). Representational State Transfer. Wikipedia. Recuperado de

http://es.wikipedia.org/wiki/Representational_State_Transfer

(2008). Introduccin a los servicios web RESTful. DOS IDEAS.

Recuperado de http://www.dosideas.com/noticias/java/314-introducciona-los-servicios-web-restful.html

Objetivo:
Saber qu es Rest y qu funciones, estructura y servicios WEB se encuentran
basados en REST.

Procedimiento:
Investigar en diversas fuentes dentro de internet y seleccionar la informacin
ms clara posible acerca del tema.

Resultados:
La Transferencia de Estado Representacional (Representational State Transfer)
o REST es un estilo de arquitectura software para sistemas hipermedia
distribuidos como la World Wide Web.
Si bien el trmino REST se refera originalmente a un conjunto de principios de
arquitectura descritos ms abajo, en la actualidad se usa en el sentido ms
amplio para describir cualquier interfaz web simple que utiliza XML y HTTP, sin
las abstracciones adicionales de los protocolos basados en patrones de
intercambio de mensajes como el protocolo de servicios web SOAP.

Los sistemas que siguen los principios REST se llaman con frecuencia
RESTful.
REST afirma que la web ha disfrutado de escalabilidad como resultado de una
serie de diseos fundamentales clave:
Cliente/Servidor: Como servicios web son cliente servidor y definen un
interface de comunicacin entre ambos separando completamente las
responsabilidades entre ambas partes.

Sin estado: Son servicios web que no mantienen estado asociado al cliente.
Cada peticin que se realiza a ellos es completamente independiente de la
siguiente. Todas las llamadas al mismo servicio sern idnticas.

Cache: El contenido de los servicios web REST ha se puede cachear de tal

forma que una vez realizada la primera peticin al servicio el resto puedan
apoyarse en la cache si fuera necesario.

Servicios Uniformes: Todos los servicios REST compartirn una forma de

invocacin y mtodos uniforme utilizando los mtodos GET, POST, PUT,
DELETE.

Arquitectura en Capas: Todos los servicios REST estn orientados hacia la

escalabilidad y un cliente REST no ser capaz de distinguir entre si est
realizando una peticin 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.

Una vez vista una introduccin al concepto de servicio REST en los siguientes
POST nos encargaremos de construir uno usando los estndares de la
plataforma JEE.

REST y HTTP
Vista esta pequea introduccin a los conceptos y reglas bsicas de REST,
podramos implementar sin problemas un protocolo que hiciera uso de dicha
arquitectura. A pesar de que podra ser un ejercicio ms que interesante si lo
que buscamos es aprender, no necesitamos hacerlo ya que afortunadamente
contamos con uno que implementa REST y que adems es la base de Internet.
Como ya he ido avanzando anteriormente, este protocolo es HTTP.
Empezaremos diciendo que para que una aplicacin sea REST al 100%, tendr
que implementar 4 principios bsicos, y pondremos esto en relacin a cmo
HTTP implementa dichos principios:

Identificacin de recursos: toda aplicacin REST debe poder

identificar sus recursos de manera uniforme. HTTP implementa esto
usando las llamadas URIs (Uniform resource identifier). Esta es la URL
que usamos tradicionalmente, y aunque hay una diferencia sutil entre
URLs y URIs [2], diremos que toda URL es una URI a su vez. Esta
identificacin del recurso no incluye la representacin del mismo, cosa
que
veremos
a
continuacin.

Recursos y representaciones: visto que todo recurso debe tener una

identificacin (URI), REST define tambin la manera en que podemos
interactuar con la representacin del mismo, ya sea para editarlo o
borrarlo, directamente del servidor. Estas representaciones se dejan a
instancias de la implementacin final del programa, pero HTTP define
distintas cabeceras de tipos, y un contenido en la respuesta, por lo que
nuestras aplicaciones pueden enviar el contenido en el formato que
quieran, siempre y cuando este contenido contenga la informacin
necesaria para poder operar con el objeto en el caso de que tengamos
permiso
para
hacerlo.

Mensajes autodescriptivos: cuando hacemos peticiones a un servidor,

ste debera devolver una respuesta que nos permita entender sin lugar
a duda cual ha sido el resultado de la operacin, as como si dicha
operacin es cacheable, si ha habido algn error, etc. HTTP implementa
esto a travs del estado y una serie de cabeceras. El cmo se usan
estos estados y cabeceras depende por entero de la implementacin de
nuestro programa, en otras palabras, REST no fuerza el contenido de
dichos elementos, por lo que el programa que se ejecuta en el servidor,
y que en ltima instancia accede a los recursos y opera con ellos, tiene
la responsabilidad de devolver estados y cabeceras que se
correspondan con el estado real de la operacin realizada. Esto es
importante tenerlo en cuenta, ya que, desgraciadamente, un gran
nmero de aplicaciones y servicios web no respetan esta regla (por lo

tanto no pueden ser considerados REST), lo que nos lleva a tener que
realizar todo tipo de workarounds y cosas por el estilo. En la segunda
parte de esta serie veremos un caso prctico de un servicio web que no
respeta esta norma, y daremos varias soluciones posibles.

HATEOAS: por ltimo, y algo que la mayora de servicios web no

cumplen, es la necesidad de incluir en las respuestas del servidor toda
aquella informacin que necesita el cliente para seguir operando con
este servicio web. En otras palabras, el cliente no tiene porqu saber
que cuando obtenemos, por ejemplo, un objeto cualquiera, tenemos
adems las opciones de modificarlo, o eliminarlo. El servidor debe
enlazar a estas operaciones en la respuesta a dicha peticin. De esta
manera, lo nico que necesita saber un cliente sobre una aplicacin
REST, es el punto de entrada (endpoint). Adems nos garantiza ms
independencia entre el cliente y el servidor. Desgraciadamente, este
ltimo principio no se implementa en la mayora de APIs que usamos
hoy en da, por lo que, siendo estrictos, podramos decir que la mayora
de servicios web no son 100% RESTful. No obstante, esto es una
limitacin menor que en prcticamente ningn caso supone un
problema.

Servicios web RESTful

As pues, teniendo claros estos conceptos y cmo 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
definicin concisa, lo cual nos dejar claro cmo tenemos que implementarlo
en nuestras aplicaciones. Un servicio web RESTful contiene lo siguiente:

URI del recurso. Por ejemplo: http://api.servicio.com/recursos/casas/1

(esto nos dara acceso al recurso Casa con el ID 1)

El tipo de la representacin 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
ms
comunes
JSON,
XML
y
TXT.

Operaciones soportadas: HTTP define varios tipos de operaciones

(verbos) [3], que pueden ser GET, PUT, POST, DELETE, PURGE, entre
otros. Es importante saber para que estn pensados cada verbo, de
modo que sean utilizados correctamente por los clientes.

Hipervnculos: por ltimo, nuestra respuesta puede incluir hipervnculos

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 aadir
una propiedad ms con los hipervnculos a las acciones que admite el
objeto.

En la imagen se muestra un ejemplo de una peticin al servicio web de GitHub.

No se muestra, pero en el contenido de la respuesta no se incluan
hipervnculos a otras acciones, por lo tanto no es una servicio web RESTful
completo.

Conclusin:
REST surgi como una alternativa para disear servicios WEB con menos
dependencia en middleware propietario (por ejemplo, un servidor de
aplicaciones), que su contraparte SOAP y los servicios basados en WSDL. De
algn modo, REST es la vuelta a la Web antes de la aparicin de los grandes
servidores de aplicaciones, ya que hace nfasis en los primeros estndares de
Internet, URI y HTTP.