Your SlideShare is downloading. ×
0
Joan Florit
Arnau Garcia
Roxana 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 reg...
REGLAS DE LA ARQUITECTURA REST
• Arquitectura cliente-servidor: separación clara entre el cliente y
el servidor
• Stateles...
REGLAS DE LA ARQUITECTURA REST
• Cacheable: HTTP la implementa con la cabecera “Cache-control”
• Sistema por capas: el cua...
REST Y HTTP
• Identificación de recursos: HTTP lo implementa las llamadas
URIs (Uniform resource identifier).
• Recursos y...
SERVICIOS WEB RESTFUL
• Un servicio web RESTful hace referencia a un servicio web que
implementa la arquitectura REST.
• U...
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.
• ...
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...
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.
 Combin...
 Tres Principales:
EXTENSIBLE: Seguridad y WS-routing*
NEUTRAL: Cualquier protocolo de transporte (HTTP,
SMTP, TCP o JM...
 Usa XML para la codificación de la serialización
(transporte de objetos tipo JSON o XML)
 Normalmente se utiliza HTTP (...
ESTRUCTURA DE LOS MENSAJES
Envelope: identifica el
documento XML cómo un
mensaje SOAP
Header: Info de encabezado
(opcional...
Reglas de procesamiento de SOAP:
El Cuerpo es sólo para los destinatarios
finales.
Secciones de la cabecera las procesa...
 La Cabecera tiene tres atributos opcionales:
Role(actor en v1.0 y 1.1): Determina si una cabecera
en particular se debe...
EJEMPLO DE CABECERA
<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-
envelope">
<env:Header...
 Seguridad: contiene info adicional de seguridad (firma
digital, claves públicas).
 Calidad de Servicio: para negociar Q...
SOAP + HTTP
USANDO SOAP CON HTTP
POST /axis/service/echo
HTTP/1.0
Host:
www.myservice.com
Content-Type: text/xml;
charset=“utf-8”
Cont...
SIGNIFICADO DE LO ANTERIOR?
 POST: método que usamos
/axis/services/echo es el path
relativo de la URL.
 El Host viene e...
SOAP ACTION
SOAP 1.0 -> Obligatorio (mensajes HTTP).
SOAP 1.1 -> Opcional.
SOAP 1.2 -> Obsoleto.
El uso que tiene es i...
UN EJEMPLO
POST /InStock HTTP/1.1
Host: www.example.org
Content-Type: application/soap+xml; charset=utf-8
Content-Length: nnn
<?xml v...
HTTP/1.1 200 OK
Content-Type: application/soap+xml; charset=utf-8
Content-Length: nnn
<?xml version="1.0"?>
<soap:Envelope...
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/soap1...
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...
REST
 POST
http://…/bank/addMoneyToAc
count?account=123456789&
money=50
 GET
http://…/bank/getAccountBal
ance?account=12...
SERIALIZACIÓN
JSON VS XML
Ambos Utilizan Unicode (codificación de
caracteres)
Los datos creados por los dos son manipulables
por herramientas gené...
Para transmitir datos tradicionales es más fácil
usar JSON ya que los datos se almacenan en
estructuras similares a las d...
Upcoming SlideShare
Loading in...5
×

REST, JERSEY & SOAP

546

Published on

Published in: Software
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
546
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
35
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Transcript of "REST, JERSEY & SOAP"

  1. 1. Joan Florit Arnau Garcia Roxana Gogonea REST, JERSEY Y SOAP
  2. 2.  Servicios REST  Jersey  Servicios SOAP  Comparación REST y SOAP  Comparación JSON y XML ÍNDICE
  3. 3. REST: REPRESENTATIONAL STATE TRANSFER
  4. 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. 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. 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. 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. 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. 9. JERSEY: RESTFUL WEB SERVICES IN JAVA
  10. 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. 11. ANOTACIONES
  12. 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. 13. JSON  Es un formato ligero para el intercambio de datos.
  14. 14. EJEMPLOS CON JSON (CLIENTE)
  15. 15. EJEMPLOS CON JSON (SERVIDOR)
  16. 16. SOAP: SIMPLE OBJECT ACCESS PROTOCOL
  17. 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. 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. 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. 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. 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. 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. 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. 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. 25. SOAP + HTTP
  26. 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. 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. 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. 29. UN EJEMPLO
  30. 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. 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. 32. EN ECLIPSE
  33. 33. CREAMOS UN DYNAMIC WEB PROJECT  Crear Package en /src  File -> New -> Dynamic Web Project
  34. 34.  Añadir la classe HelloWorld.java CREAMOS UNA CLASE “HELLOWORLD”  Luego BD->New->web service
  35. 35.  Le damos a Browse y buscamos helloworld
  36. 36.  Luego ajustamos el service implementation y el client Type
  37. 37.  Por último se nos ha creado un proyecto Cliente  Y se ejecuta el resultado
  38. 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. 39. COMPARATIVA
  40. 40. REST VS SOAP
  41. 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. 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. 43. SERIALIZACIÓN JSON VS XML
  44. 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. 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
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×