REST, JERSEY & SOAP
Transcript of REST, JERSEY & SOAP
Joan FloritArnau GarciaRoxana Gogonea
REST, JERSEY Y SOAP
Servicios REST
Jersey
Servicios SOAP
Comparación REST y SOAP
Comparación JSON y XML
ÍNDICE
REST:REPRESENTATIONAL STATE TRANSFER
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.
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
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
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.
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
JERSEY:RESTFUL WEB SERVICES IN JAVA
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
ANOTACIONES
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
JSON
Es un formato ligero para el intercambio de datos.
EJEMPLOS CON JSON (CLIENTE)
EJEMPLOS CON JSON (SERVIDOR)
SOAP:SIMPLE OBJECT ACCESS PROTOCOL
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
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
*
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
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
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
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
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>
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
SOAP + HTTP
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.
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>
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
UN EJEMPLO
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
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
EN ECLIPSE
CREAMOS UN DYNAMIC WEB PROJECT
Crear Package en /src
File -> New -> Dynamic Web Project
Añadir la classe HelloWorld.java
CREAMOS UNA CLASE “HELLOWORLD”
Luego BD->New->web service
Le damos a Browse y buscamos helloworld
Luego ajustamos el service implementation y el client Type
Por último se nos ha creado un proyecto Cliente
Y se ejecuta el resultado
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
COMPARATIVA
REST VS 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
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)
SERIALIZACIÓN JSON VS XML
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
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