El documento compara las tecnologías REST, Jersey y SOAP. REST define principios para la interacción entre componentes usando protocolos como HTTP. Jersey es una implementación de REST en Java. SOAP usa XML para serializar peticiones y respuestas entre objetos en procesos diferentes, usualmente sobre HTTP.

1. Joan Florit
Arnau Garcia
Roxana Gogonea
REST, JERSEY Y SOAP

2.  Servicios REST
 Jersey
 Servicios SOAP
 Comparación REST y SOAP
 Comparación JSON y XML
ÍNDICE

3. REST:
REPRESENTATIONAL
STATE TRANSFER

4. SERVICIO REST
REST es un conjunto de principios, que define la interacción entre
distintos componentes, es decir, las reglas que dichos
componentes tienen que seguir. El protocolo más usado que
cumple esta definición, es el protocolo HTTP.
• Toda aplicación web bajo el protocolo HTTP es a su vez una
aplicación REST.
• No implica en absoluto que todas las aplicaciones web sean
servicios web RESTful.

5. REGLAS DE LA ARQUITECTURA REST
• Arquitectura cliente-servidor: separación clara entre el cliente y
el servidor
• Stateless: el servidor no almacena el estado del cliente
Con estado Sin estado

6. REGLAS DE LA ARQUITECTURA REST
• Cacheable: HTTP la implementa con la cabecera “Cache-control”
• Sistema por capas: el cual implica que un componente no puede
ver más allá de la capa inmediata con la cual interactúa
• Interfaz uniforme: la interfaz de comunicación entre un cliente y
el servidor no depende del servidor o del cliente

7. REST Y HTTP
• Identificación de recursos: HTTP lo implementa las llamadas
URIs (Uniform resource identifier).
• Recursos y representaciones: Al invocar la URL, el cliente
obtiene una representación del recurso.
• Mensajes autodescriptivos: Ver en la respuesta claramente el
resultado de la operación, si es cacheable o ha habido errores.
• HATEOAS: las operaciones que se pueden realizar con un API
sean auto-descubribles a través de hipervínculos.

8. SERVICIOS WEB RESTFUL
• Un servicio web RESTful hace referencia a un servicio web que
implementa la arquitectura REST.
• Un servicio web RESTful contiene lo siguiente:
o URI del recurso
o El tipo de la representación de dicho recurso
o Operaciones soportadas: GET, PUT, POST, DELETE
o Hipervínculos

9. JERSEY:
RESTFUL WEB
SERVICES IN JAVA

10. JERSEY
• Jersey es la implementación de referencia para REST sobre
HTTP.
• Contiene un servidor REST y un cliente REST.
• Objetivos generales:
o Definir servicios en forma de POJOs
o Mapear peticiones y respuestas HTTP a esos POJOs
o Mapear parámetros de URL a parámetros de entrada a los
métodos
o Declaración del formato de los contenidos recibidos o emitidos

11. ANOTACIONES

12. EJEMPLO BÁSICO DE JERSEY
1. Crear proyecto básico de Wicket
2. Añadir librerías de Jersey en el pom.xml
3. Añadir ficheros fuente de la app en resources/src/main/java un
package llamado eetac.ea.demoJersey y allí el .java
4. Configurar aplicación web para que llame a la implementación
REST

13. JSON
 Es un formato ligero para el intercambio de datos.

14. EJEMPLOS CON JSON (CLIENTE)

15. EJEMPLOS CON JSON (SERVIDOR)

16. SOAP:
SIMPLE OBJECT
ACCESS PROTOCOL

17.  Protocolo utilizado en los servicios Web.
 Dos objetos en diferentes procesos se comunican
mediante datos XML.
 Combina solicitudes SOAP, con respuestas sobre un
protocolo de transporte.
SIMPLE OBJECT ACCESS PROTOCOL

18.  Tres Principales:
EXTENSIBLE: Seguridad y WS-routing*
NEUTRAL: Cualquier protocolo de transporte (HTTP,
SMTP, TCP o JMS)
INDEPENDIENTE del modelo de programación
CARACTERÍSTICAS
mecanismo que puede identificar servicios
web independientemente del protocolo de
transporte
*

19.  Usa XML para la codificación de la serialización
(transporte de objetos tipo JSON o XML)
 Normalmente se utiliza HTTP (GET, POST, PUT,
DELETE…)
 Protocolo de mensajes Solicitud / Respuesta
 Soporta respuestas de Error (fault)
CARACTERÍSTICAS
SOAP = XML + HTTP

20. ESTRUCTURA DE LOS MENSAJES
Envelope: identifica el
documento XML cómo un
mensaje SOAP
Header: Info de encabezado
(opcional)
Body: contiene la información
de llamada y respuesta

21. Reglas de procesamiento de SOAP:
El Cuerpo es sólo para los destinatarios
finales.
Secciones de la cabecera las procesan
intermediarios, así cómo receptores finales.
Las cabeceras son los elementos de
extensibilidad para definir otras
características.
ESTRUCTURA Y PROCESADO DE SOAP

22.  La Cabecera tiene tres atributos opcionales:
Role(actor en v1.0 y 1.1): Determina si una cabecera
en particular se debe procesar.
mustUnderstand: si es “true”, los nodos deben conocer
cómo procesar la cabecera.
Relay: Indica si un bloque de la cabecera debe ser
remitida (forwarded).
ATRIBUTOS DE LA CABECERA

23. EJEMPLO DE CABECERA
<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-
envelope">
<env:Header>
<m:reservation xmlns:m=“…"
env:role="http://www.w3.org/2003/05/soap-
envelope/role/next" env:mustUnderstand="true">
<m:reference>uuid:093a2da1-q345-739r-ba5d-pqff98fe8j7d
</m:reference>
<m:dateAndTime>2001-11-29T13:20:00.000-05:00
</m:dateAndTime>
</m:reservation>
<n:passenger xmlns:n=“…"
env:role="http://www.w3.org/2003/05/soap-
envelope/role/next" env:mustUnderstand="true">
<n:name>Åke Jógvan Øyvind</n:name>
</n:passenger>
</env:Header>

24.  Seguridad: contiene info adicional de seguridad (firma
digital, claves públicas).
 Calidad de Servicio: para negociar QoS particulares
(p. ej: fiabilidad en los mensajes).
 Soporta el Estado de Sesión: En servicios donde se
requiere mantenerlo.
 Equivalente a las cookies en HTTP
 Ponemos el identificador de sesión en el header.
EJEMPLOS DE USO DE LA CABECERA

25. SOAP + HTTP

26. USANDO SOAP CON HTTP
POST /axis/service/echo
HTTP/1.0
Host:
www.myservice.com
Content-Type: text/xml;
charset=“utf-8”
Content-Length: nnn
SOAPAction=“”
<SOAP:env>
…
</SOAP:evn>
 Conociendo un servidor
HTTP que entiende SOAP.
 Podemos construir un
mensaje HTTP con un
payload en SOAP.
 Escribimos el mensaje en
el socket remoto.

27. SIGNIFICADO DE LO ANTERIOR?
 POST: método que usamos
/axis/services/echo es el path
relativo de la URL.
 El Host viene en una línea
separada.
 Host: nombre del host.
 Content-Type: Tipo de
contenido que enviamos.
 Debemos usar text/xml para
SOAP.
 Se suelen llamar mime-types.
 Content-Length: número de
carácteres del payload HTTP.
 SOAPAction*
POST /axis/service/echo
HTTP/1.0
Host:
www.myservice.com
Content-Type: text/xml;
charset=“utf-8”
Content-Length: nnn
SOAPAction=“”
<SOAP:env>
…
</SOAP:evn>

28. SOAP ACTION
SOAP 1.0 -> Obligatorio (mensajes HTTP).
SOAP 1.1 -> Opcional.
SOAP 1.2 -> Obsoleto.
El uso que tiene es informar al servidor Web
de algún uso específico previsto.
El servidor lo podria usar para cancelar el
procesamiento del mensaje SOAP si el servicio no
está disponible.
SOAPAction=“” el servicio previsto es
idéntico a la ruta relativa de la línea POST.
/axis/services/Echo

29. UN EJEMPLO

30. POST /InStock HTTP/1.1
Host: www.example.org
Content-Type: application/soap+xml; charset=utf-8
Content-Length: nnn
<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-
encoding">
<soap:Body xmlns:m="http://www.example.org/stock">
<m:GetStockPrice>
<m:StockName>IBM</m:StockName>
</m:GetStockPrice>
</soap:Body>
</soap:Envelope>
SOAP REQUEST

31. HTTP/1.1 200 OK
Content-Type: application/soap+xml; charset=utf-8
Content-Length: nnn
<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-
encoding">
<soap:Body xmlns:m="http://www.example.org/stock">
<m:GetStockPriceResponse>
<m:Price>34.5</m:Price>
</m:GetStockPriceResponse>
</soap:Body>
</soap:Envelope>
SOAP RESPONSE

32. EN ECLIPSE

33. CREAMOS UN DYNAMIC WEB PROJECT
 Crear Package en /src
 File -> New -> Dynamic Web
Project

34.  Añadir la classe
HelloWorld.java
CREAMOS UNA CLASE “HELLOWORLD”
 Luego BD->New->web service

35.  Le damos a Browse y buscamos
helloworld

36.  Luego ajustamos el service
implementation y el client Type

37.  Por último se nos ha creado un
proyecto Cliente
 Y se ejecuta el resultado

38. Wikipedia:
 http://en.wikipedia.org/wiki/SOAP
Especificaciones:
 http://www.w3.org/TR/soap/
 http://www.w3.org/TR/soap12-part1/
Más información:
 http://www.xml.com/pub/rg/SOAP
 http://msdn.microsoft.com/en-us/magazine/bb985060.aspx
Demo:
http://javapostsforlearning.blogspot.com.es/2013/03/soap-web-
service-example-in-java-using.html
 SOA in Practice, The Art of Distributed System Design, Agosto
2007
REFERENCIAS, RECURSOS

39. COMPARATIVA

40. REST VS SOAP

41.  En REST únicamente se usan los métodos de HTTP.
 REST estrictamente no guarda la sesión puesto que
se define sin estado.
 SOAP crea sesiones para invocar a los métodos
remotos.
 En una pila de protocolos SOAP iría justo encima de
HTTP.
 En cambio REST propone HTTP como nivel de
aplicación.
REST VS SOAP

42. REST
 POST
http://…/bank/addMoneyToAc
count?account=123456789&
money=50
 GET
http://…/bank/getAccountBal
ance?account=123456789
REST VS SOAP
SOAP
 POST
bank = new
SOAPProxy(“http://…..”)
bank.addMoneyToAccount(acc
ount 123456789, 50 euro)
 GET
bank = new
SOAPProxy(“http://…..”)
bank.getAccountBalance(acco
unt 123456789)

43. SERIALIZACIÓN
JSON VS XML

44. Ambos Utilizan Unicode (codificación de
caracteres)
Los datos creados por los dos son manipulables
por herramientas genéricas
Son formatos fáciles de distribuir a los usuarios
JSON almacena datos clásicos (texto y números)
XML permite almacenar todo tipo de datos.
En JSON los datos se almacenan en vectores y
registros.
XML almacena los datos en árboles.
JSON VS XML

45. Para transmitir datos tradicionales es más fácil
usar JSON ya que los datos se almacenan en
estructuras similares a las de programación de
objetos.
JSON sólo ofrece opciones para la transferencia
de los datos sin formato.
XML es mejor compartiendo documentos
(tablas, gráficos…).
JSON VS XML