REST, JERSEY & SOAP

45
Joan Florit Arnau Garcia Roxana Gogonea REST, JERSEY Y SOAP

Transcript of REST, JERSEY & SOAP

Page 1: REST, JERSEY & SOAP

Joan FloritArnau GarciaRoxana Gogonea

REST, JERSEY Y SOAP

Page 2: REST, JERSEY & SOAP

Servicios REST

Jersey

Servicios SOAP

Comparación REST y SOAP

Comparación JSON y XML

ÍNDICE

Page 3: REST, JERSEY & SOAP

REST:REPRESENTATIONAL STATE TRANSFER

Page 4: REST, JERSEY & SOAP

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.

Page 5: REST, JERSEY & SOAP

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

Page 6: REST, JERSEY & SOAP

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

Page 7: REST, JERSEY & SOAP

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.

Page 8: REST, JERSEY & SOAP

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 recursoo El tipo de la representación de dicho recursoo Operaciones soportadas: GET, PUT, POST, DELETEo Hipervínculos

Page 9: REST, JERSEY & SOAP

JERSEY:RESTFUL WEB SERVICES IN JAVA

Page 10: REST, JERSEY & SOAP

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 POJOso Mapear peticiones y respuestas HTTP a esos POJOso Mapear parámetros de URL a parámetros de entrada a

los métodoso Declaración del formato de los contenidos recibidos o

emitidos

Page 11: REST, JERSEY & SOAP

ANOTACIONES

Page 12: REST, JERSEY & SOAP

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

Page 13: REST, JERSEY & SOAP

JSON

Es un formato ligero para el intercambio de datos.

Page 14: REST, JERSEY & SOAP

EJEMPLOS CON JSON (CLIENTE)

Page 15: REST, JERSEY & SOAP

EJEMPLOS CON JSON (SERVIDOR)

Page 16: REST, JERSEY & SOAP

SOAP:SIMPLE OBJECT ACCESS PROTOCOL

Page 17: REST, JERSEY & SOAP

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

Page 18: REST, JERSEY & SOAP

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

*

Page 19: REST, JERSEY & SOAP

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

Page 20: REST, JERSEY & SOAP

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

Page 21: REST, JERSEY & SOAP

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

Page 22: REST, JERSEY & SOAP

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

Page 23: REST, JERSEY & SOAP

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>

Page 24: REST, JERSEY & SOAP

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

Page 25: REST, JERSEY & SOAP

SOAP + HTTP

Page 26: REST, JERSEY & SOAP

USANDO SOAP CON HTTP

POST /axis/service/echo HTTP/1.0

Host: www.myservice.com

Content-Type: text/xml; charset=“utf-8”

Content-Length: nnnSOAPAction=“”<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.

Page 27: REST, JERSEY & SOAP

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: nnnSOAPAction=“”<SOAP:env>

…</SOAP:evn>

Page 28: REST, JERSEY & SOAP

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

Page 29: REST, JERSEY & SOAP

UN EJEMPLO

Page 30: REST, JERSEY & SOAP

POST /InStock HTTP/1.1Host: www.example.orgContent-Type: application/soap+xml; charset=utf-8Content-Length: nnn

<?xml version="1.0"?><soap:Envelopexmlns: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

Page 31: REST, JERSEY & SOAP

HTTP/1.1 200 OKContent-Type: application/soap+xml; charset=utf-8Content-Length: nnn

<?xml version="1.0"?><soap:Envelopexmlns: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

Page 32: REST, JERSEY & SOAP

EN ECLIPSE

Page 33: REST, JERSEY & SOAP

CREAMOS UN DYNAMIC WEB PROJECT

Crear Package en /src

File -> New -> Dynamic Web Project

Page 34: REST, JERSEY & SOAP

Añadir la classe HelloWorld.java

CREAMOS UNA CLASE “HELLOWORLD”

Luego BD->New->web service

Page 35: REST, JERSEY & SOAP

Le damos a Browse y buscamos helloworld

Page 36: REST, JERSEY & SOAP

Luego ajustamos el service implementation y el client Type

Page 37: REST, JERSEY & SOAP

Por último se nos ha creado un proyecto Cliente

Y se ejecuta el resultado

Page 38: REST, JERSEY & SOAP

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.aspxDemo: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

Page 39: REST, JERSEY & SOAP

COMPARATIVA

Page 40: REST, JERSEY & SOAP

REST VS SOAP

Page 41: REST, JERSEY & SOAP

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

Page 42: REST, JERSEY & SOAP

REST

POSThttp://…/bank/addMoneyToAccount?account=123456789&money=50

GEThttp://…/bank/getAccountBalance?account=123456789

REST VS SOAP

SOAP

POSTbank = new SOAPProxy(“http://…..”)bank.addMoneyToAccount(account 123456789, 50 euro)

GETbank = new SOAPProxy(“http://…..”)bank.getAccountBalance(account 123456789)

Page 43: REST, JERSEY & SOAP

SERIALIZACIÓN JSON VS XML

Page 44: REST, JERSEY & SOAP

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

Page 45: REST, JERSEY & SOAP

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