FORMACIÓN EN NUEVAS TECNOLOGÍAS. Web Services RESTful

(1)

FORMACIÓN EN NUEVAS TECNOLOGÍAS

Web Services RESTful

ICONO TRAINING FORMADOR

www.iconotc.com [email protected]

linkedin.com/company/icono-training-consulting

Javier Martín

Consultor y Formador en las Tecnologías de la información.

Formación en Nuevas Tecnologías

(2)

WEB SERVICES RESTful

-Avanzado-DURACIÓNl 14 horas LUGAR/FECHAS /HORARIO:



Madrid. 13 y 14 de Febrero de 2019. De 9:00 hs a 14:00 y de 15:00 a 17:00 hs. CONTENIDOS:



1. Diseño e implementación de recursos REST con JAX-RS



2. JAX-RS Injection



3. API Cliente JAX-RS 2.0. Clientes de bajo nivel



4. Control de Errores y respuestas del servidor



5. JAX-RS asíncrono



6. Seguridad bajo JAX-RS



7. Creación de servicios Web RESTful con Spring framework y Spring Boot



8. Motivación para usar Spring Boot



9. Definición de proyectos Spring Boot



10. Anotaciones esenciales para crear Servicios Web RESTful bajo Spring

www.iconotc.com

Servicios REST en

Java

(3)

SERVICIOS WEB

Introducción

¿Qué es un Servicio Web? Según Microsoft:

 “… es una entidad programable que proporciona un elemento de funcionalidad determinado, como lógica de aplicación … (accesible) mediante estándares de Internet … como XML y HTTP.”

Según Sun:

 “… es un componente software con las siguientes características: 1) Es accesible a través del interfaz SOAP,

2) Su interfaz se describe en un documento WSDL.” Según Wikipedia:

 “… es un conjunto de protocolos y estándares que sirven para intercambiar datos entre aplicaciones.”

Componentes que permiten a las aplicaciones compartir datos siguiendo un 21

(4)

Introducción

• Pero esto no es todo, aun podemos definirlo de mas formas De otra forma:

 “A través de una interfaz estándar … permite el funcionamiento de una serie de sistemas heterogéneos como un conjunto integrado.”

Simplificando:

 “Sistema diseñado para soportar interoperabilidad entre máquinas sobre una red.”

Introducción

• ¿Qué es REALMENTE un Servicio Web?

• Es una «elemento» accesible a través de Internet, mediante la invocación remota

• Se deben de alojar en un Servidor Web. (que soporte Web Services) • Son:

 Autocontenido  Autodescrito  Modular e

 Independiente de Plataforma

• Utilizan estándares (XML, SOAP, RPC) para poder ofrecer sus servicios 23

(5)

Introducción

¿Qué es REALMENTE un Servicio Web? • Un servicio web es:

 Una aplicación remota

 Descrito usando WSDL (Web Service Description Language)  Accediendo mediante SOAP (Simple Object Access Protocol)

 Todo esto bajo una serie de reglas/estándares definidas por WS-I Basic Profile • El WS-I (Web Services Organización de Integración) es un grupo de

proveedores (Microsoft, IBM, BEA, Sun Microsystems, Oracle, HP, y otros) que se han unido para garantizar que los servicios web son interoperables en todas las plataformas.

• Para ello, han creado una recomendación llamado Basic Profile 1.1, que define un conjunto de reglas para el uso de XML, SOAP y WSDL para crear servicios web interoperables.

Introducción

• Los servicios Web son sistemas que se comunican principalmente a través de HTTP.

• Pero puede comunicarse a través de otros protocolos de también populares y con posibilidades de ser tratado (inspeccionado, transformado,

persistido, etc) como XML o JSON

• Normalmente, las cargas útiles de comunicaciones de servicios Web suelen ser generadas en XML.

• También es posible la comunicación de datos binarios compactos entre Web Services.

(6)

Web Services. Historia

AÑO Descripción

1976 Aparición de RPC (Remote Procedure Call) en Sistema Unix

1990 Aparición de DCE (Distributed Computing Environment) que es un sistema de software para computación distribuida, basado en RPC.

1991 Aparición de Microsoft RPC basado en DCE para sistemas Windows.

1992 Aparición de DCOM (Microsoft) y CORBA (ORB) para la creación de componentes software distribuidos. 1997 Aparición de Java RMI en JDK 1.1

1999 Aparición de SOAP 1.0, WSDL

2000 Definición REST

Arquitectura SOA y Web Services

• Los servicios Web y la Arquitectura SOA están muy relacionados. • SOA (Arquitectura Orientada a Servicios)

• SOA es una arquitectura de software que definen el uso de servicios como soporte a los requisitos del negocio.

• Su objetivo es alcanzar un mínimo acoplamiento entre agentes software, con el fin de permitir a la empresa organizar y hacer uso de múltiples procesos.

• Los Servicio Webs son las unidades de trabajo, realizados por un proveedor de servicios, para alcanzar un resultado final deseado por un consumidor del servicio.

(7)

Arquitectura SOA y Web Services

• Con SOA, las aplicaciones software ya no son enormes bloques de funciones y procesos.

• Con SOA las aplicaciones se componen de servicios modulares ensamblados, pequeños y concretos.

Arquitectura SOA y Web Services

• En un sistema SOA, los servicios que pueden integrar deben de ser: • Reutilizables

 Todo servicio debe ser diseñado y construido pensando en su reutilización. • Disponer de un contrato Formal

 Debe proporcionar un contrato en el cual figuren: el nombre del servicio, su forma de acceso, las funcionales que ofrece, los datos de entrada de cada una de las funcionalidades y los datos de salida

• Bajo Acoplamiento

 Tienen que ser independientes los unos de los otros, utilizando el contrato existente cada vez que se quiera ejecutar un servicio.

• Autónomos

 Todo Servicio debe tener su propio entorno de ejecución. • Permitir composición y Descubrimiento

(8)

Arquitectura SOA y Web Services

• En un sistema de SOA, un servicio muy simple puede consistir en una sola función.

• El modelo de implementación de este modelo es sencillo y familiar para los programadores(Trabajo con funciones).

• Esta simplicidad, también permiten la reutilización de código a través de la composición de los nuevos servicios de los ya existentes.

• Un sistema de SOA puede ser bastante complejo, pero la complicación surge de la composición y no de la creación de los propios componentes de la composición (servcios).

Arquitectura SOA y Web Services

• Los servicios Web son ideales como componentes en un sistema de SOA.

• Un servicio web debe consistir en una o varias operaciones. • Cada una de estas operaciones se implementa como una llamada a la

función sin estado.

• En Java, un servicio web bien diseñado, es una clase que: • Tiene métodos de instancia → Operaciones de servicio

• No tiene atributos → para no pueda afectar al resultado devuelto • En el contexto de SOA:

• Proveedor suministra la funcionalidad del servicio

• Consumidor es un cliente que emite peticiones contra las operaciones del servicio. 31

(9)

Características diferenciadoras de WS

• Varias características distinguen a los servicios web desde otros sistemas de software distribuidos

1. Infraestructura Abierta

 Los servicios Web se implementan utilizando estándares de la industria, protocolos independientes del proveedor y lenguajes.

 Los servicios web pueden aprovecharse de las redes, el formato de los datos, la seguridad y otras infraestructuras ya existentes

2. Plataforma y Lenguaje Transparente

 Los servicios web pueden ser creados, publicados y consumidos en varias plataformas de hardware y bajo diferentes sistemas operativos.

3. Diseño Modular

 Los WS son pequeños programas que pueden ser integrados/orquestados en grandes sistemas.

 Un principio básico del diseño de servicios web es comenzar con operaciones muy simples de servicio, para posteriormente poder ser orquestados para trabajar con otros servicios, y así indefinidamente

Diferentes tipos de Web Services

• Podemos encontrar diversos estilos de Servicios Web: • XML-RPC (RPC, Llamadas a Procedimientos Remotos)

 Es un protocolo que permite a un programa ejecutar código en otra máquina remota sin tener que preocuparse por las comunicaciones entre ambos.

 Es el precursor de SOAP ( Java RMI, .NET Remoting, CORBA ) • Basados en SOAP (o denominados comúnmente WS)

 Los Servicios Web basados en SOA son soportados por la mayor parte de desarrolladores de software y analistas

 Se basan en los estándares: SOAP, WSDL, UDDI., que se comunican con aplicaciones a través de HTML utilizando XML

• REST (REpresentational StateTransfer)

 Es una técnica de arquitectura software para sistemas hipermedia distribuidos como WWW.  Se usa para describir cualquier interfaz web simple que utiliza XML y HTTP, sin protocolos

basados en patrones de intercambio de mensajes como el protocolo de servicios web SOAP  Se centra más en interactuar con recursos con estado, que con mensajes y operaciones. 33

(10)

Diferentes tipos de Web Services

(11)

TECNOLOGÍAS DE SERVICIOS WEB

El protocolo SOAP

• SOAP Simple Object Access Protocol.

• SOAP es un protocolo estándar que define cómo dos objetos en diferentes procesos pueden comunicarse por medio de intercambio de datos XML.

• Fundamentalmente, SOAP es la capa de transporte por defecto para los servicios Web.

(12)

El protocolo SOAP

• Este protocolo consiste de tres partes: • Envelope

 Identifica el documento XML como un mensaje SOAP.  En el cual define qué hay en el mensaje y cómo procesarlo.  Marca el inicio y el final del mensaje SOAP

• Header(opcional)

 Cuando se utiliza el protocolo SOAP sobre HTTP, las cabeceras HTTP proporcionan información sobre el tipo de contenido, longitud del contenido , y el destinatario del mensaje. • Body

 Contiene información de la llamada y respuesta.

 El cuerpo es un elemento obligatorio que contiene la información para el destinatario del mensaje

El protocolo SOAP

(13)

Descripción de servicios Web con WSDL

• WSDL (Web Services Description Language)

• WSDL es una tecnología que se utiliza para describir la interfaz pública de un servicio Web.

• Está basado y creado en lenguaje XML.

• WSDL es un estándar desarrollado por el W3C que describe: • Lo que hace un servicio

• Cómo invocar sus operaciones • Y dónde encontrarlo.

Descripción de servicios Web con WSDL

• Un documento WSDL tiene los siguientes elementos: • Tipos de Datos <types>

 Define los tipos de datos usados en los mensajes.

 Se utilizan los tipos definidos en la especificación de esquemas XML. • Mensajes <message>

 Se utilizan para definir el formato de los datos intercambiados entre un consumidor de servicios Web y el proveedor de servicios.

• Tipos de Puerto <portType>:

 Se utiliza para especificar las operaciones del servicio Web. • Bindings <binding>:

 Describe el protocolo, formato de datos y la seguridad de un elemento <portType>  Los Bindings estándar son HTTP o SOAP, o uno propio.

• Servicios <service>:

 Conjunto de direcciones y puertos para poder interactuar con los servicios. 43

(14)

Descripción de servicios Web con WSDL

<soap:address location="http://localhost:64082/CreditService/CreditCheckEndpointBean"/> </port> </service> <portType name="CreditCheckEndpointBean"> <operation name="CreditCheck"> <input message="tns:CreditCheck"/> <output message="tns:CreditCheckResponse"/> </operation> </portType>

Publicación de servicios Web con UDDI

• UDDI (Universal Description, Discovery and Integration).

• UDDI es una iniciativa industrial abierta, cuyo principal propósito es contener un catálogo de Servicios Webs de Internet.

• Objetivos

• Ser accedido por los mensajes SOAP • Descubrir Servicios

• Obtener documentos WSDL con la descripción de los contratos(requisitos del protocolo, formatos de mensajes, etc del servicio) para poder utilizar los Servicios. 45

(15)

Publicación de servicios Web con UDDI

• UDDI utiliza lenguaje XML para realizar los registros y localizar los Servicios Webs.

• Los Sistemas UDDI pueden ser utilizados a nivel Internet o más comúnmente Intranet.

Publicación de servicios Web con UDDI

• UDDI consta de tres partes: • Páginas blancas

 Dan información acerca de la empresa que presta el servicio.

– Nombre, Dirección, Persona de contacto, teléfono, etc

 Usando esta información, es posible encontrar un servicio sobre el que se conoce alguna información

• Páginas amarillas

 Proporcionan una clasificación del servicio o negocio.

 Esta clasificación se basa en taxonomías estándar, geográficas, etc.

 Pueden existir mas de una página amarilla por empresa ( si esta proporciona varios servicios)

• Páginas verdes

 Se utilizan para describir la forma de acceder a un servicio web.

 Dirección, parámetros y referencias del servicio necesarios.  Especificaciones indicadas en WSDL

(16)

REST

• REST (REpresentational State Transfer)

• REST es un patrón de arquitectura de software que utiliza HTTP para descubrir, consultar y manipular los recursos en un entorno

descentralizado y distribuido.

• En la actualidad REST ha ganado popularidad a SOAP-WDSL debido a su simplicidad.

• Cuando se usa REST, el cliente tiene acceso a un recurso en el servidor,

utilizando el URI y el conjunto estándar de métodos HTTP (GET, POST, PUT

y DELETE).

• En respuesta, el servidor devuelve un documento que contiene el estado actual o previsto de los recursos.

REST

• Servicios Web RESTful

• Servicios web RESTful son servicios que se construyen sobre la base de los principios REST antes mencionados.

• Servicios web RESTful utilizan HTTP e implementar las operaciones que se asignan a los métodos HTTP comunes:

import javax.ws.rs.Consumes; import javax.ws.rs.PUT; import javax.ws.rs.Path; import javax.ws.rs.PathParam; import javax.ws.rs.Produces; @Path("creditCheck") public class CreditCheck {

@PUT

@Consumes("text/plain") @Produces("text/plain") @Path("isValid")

public boolean isValid(@PathParam("cardNumber") String ccNumber) {

return true; } 49

(17)

Comparación SOAP v REST

Apache CXF

• Apache CXF es un framework completo, de código abierto para servicios web.

• Se originó como combinación de dos proyectos de código abierto: • Celtix desarrollado por IONA Technologies

• XFire desarrollado por un equipo basado en Codehaus.

• El nombre CXF se deriva de la combinación de los nombres de proyecto "Celtix" y "XFire".

• CXF frecuentemente se emplea en conjunto con otros frameworks de Apache (ServiceMix, Camel y ActiveMQ) en proyectos de infraestructura con arquitecturas orientadas a servicios (SOA)

(18)

Apache CXF

• CXF incluye un conjunto amplio de características, pero se concentra principalmente en las siguientes áreas:

• Soporte de estándares en servicios web:  SOAP

 WS-Security  WS-*

• JAX-WS API para el desarrollo de servicios web.

• JAX-RS (JSR 311 1.1) API para el desarrollo de servicios web del tipo RESTful.

• Soporte de Maven como herramienta. • Capas de transporte HTTP y JMS.

JAX-WS

• Java API for XML Web Services (JAX-WS) es una API de Java para la creación de servicios web.

• Es parte de la plataforma Java EE de Sun Microsystems.

• JAX-WS utiliza anotaciones, para simplificar el desarrollo y despliegue de los clientes y puntos finales de servicios web.

• Forma parte del Java Web Services Development Pack.

• JAX-WS 2.0 reemplazó a la API JAX-RPC en Java EE 5 JAX-WS también es uno de los fundamentos de WSIT.

(19)

JAX-RS

• JAX-RS: Java API for RESTful Web Services es una API de Java que proporciona soporte en la creación de servicios web de acuerdo con el estilo arquitectónico Representational State Transfer (REST).

• JAX-RS usa anotaciones, introducidas en Java SE 5, para simplificar el desarrollo y despliegue de los clientes y puntos finales de los servicios web.

• JAX-RS forma parte de Java EE 6.

• Al ser parte oficial de Java EE no se requiere configuración para comenzar a usar JAX-RS.

• Para los entornos que no son Java EE 6 se requiere una (pequeña) entrada en el descriptor de despliegue web.xml.

JAX-RS

• Entre las implementaciones de JAX-RS se incluyen: • Apache CXF

 un framework de servicios web de código abierto. • Jersey

 la implementación de referencia de Sun (ahora Oracle). • RESTeasy

 implementación de JBoss. • Restlet

 creado por Jerome Louvel, un pionero en frameworks de REST. • Apache Wink

 proyecto de Apache Software Foundation Incubator, el módulo del servidor implementa JAX-55

(20)

IMPLEMENTACIÓN DE SERVICIOS

WEB REST

Introducción a los Servicios REST

• REST y SOAP son muy diferentes. • SOAP:

 Es un protocolo de mensajería • REST:

 Es un estilo de arquitectura de software para sistemas hipermedia distribuidos.  Sistemas en los que el texto , gráficos , audio y otros medios de comunicación se

almacenan en una red e interconectados a través de hipervínculos . • WWW es un sistema REST (web estática, web dinámica no ).

• En la Web, HTTP es a la vez un protocolo de transporte y un sistema de mensajería(las peticiones y respuestas HTTP son mensajes).

• Roy Fielding, en el 2000 acuñó el acrónimo REST, (autor principal de la especificación HTTP y cofundador de la Fundación de Software Apache)

(21)

Introducción a los Servicios REST

• Lo primero es aclarar que REST no es una tecnología, ni siquiera una arquitectura, en un convenio:

Una familia de arquitecturas de servicios distribuidos que cumplan con una serie de requisitos definidos REST. • Estos requisitos REST son:

• Se publican Recursos.

 Un dato, una operación, un numero de empleado 33, empleado 44, etc.

• Los servicios REST no publican un conjunto de métodos u operaciones, publican RECURSOS.

• Cada recurso dispone de un identificador único.

• Cada recurso debe de tener una o varias representaciones de su estado (XML, HTML, PDF, etc)

Introducción a los Servicios REST

(22)

Introducción a los Servicios REST

• REST (REpresentation State Transfer )

• Nos permite utilizar cualquier interfaz web simple que utiliza HTTP, sin las abstracciones/restricciones de los protocolos basados en patrones de intercambio de mensajes.

• Los servicios que siguen los principios de REST habitualmente se denominan RESTful.

• REST se basa en varios componentes principales: • Recursos

• URI

• Representaciones • Solicitudes HTTP

REST y HTTP

• HTTP es una pieza fundamental en World Wide Web, y especifica como intercambiar entre cliente y servidor recursos web.

• Es un protocolo idóneo para implementar servicios web, ya que sigue los principios REST.

• Características de HTTP:

• Es un protocolo de nivel de aplicación y algo de presentación. • Está diseñado para ser ejecutado sobre TCP o sobre TLS/SSL.

• Se basa en un paradigma sencillo petición/respuesta, es decir, es un protocolo

stateless.

(23)

REST y HTTP

• Cuando realizamos una petición HTTP, el mensaje consta de: • Primera línea de texto indicando la versión del protocolo utilizado, el verbo y el URI

 El verbo indica la acción a realizar sobre el recurso web localizado en la URI • Posteriormente vendrían las cabeceras (opcionales)

• Después el cuerpo del mensaje, que contiene un documento, que puede estar en cualquier formato ( XML, HTML, JSON → Content-type )

REST y HTTP

• Los mensajes HTTP de respuesta siguen el mismo formato que los de envío.

• Sólo difieren en la primera línea

• Donde se indica un código de respuesta junto a una explicación textual de dicha respuesta.

• El código de respuesta indica si la petición tuvo éxito o no. 65

(24)

Componentes de REST

Recursos

• Un recurso es cualquier elemento que dispone de un URI correcto y único. • Es cualquier cosa que sea direccionable a través de internet.

• Estos recursos pueden ser manipulados por clientes y servidores.  Una noticia.

 La temperatura en Madrid a las 22:00h.  Un estudiante de alguna clase en alguna escuela  Un ejemplar de un periódico, etc

• En REST todos los recursos comparten una interfaz única y constante. (http://...) • Todos los recursos tienen las mismas operaciones (CRUD)

CREATE, READ, UPDATE, DELETE

Componentes de REST

URI (Uniform Resource Identifier)

• Los URI son los identificadores globales de recursos en la web, y actúan de manera efectiva como UUIDs REST.

• Hay 2 tipos de URIs : URL y URN

 URL s Identifican un recurso de red mediante una IP o un DNS

 URNs son simples UUIDs lógicos con un espacio de nombres asociados

• URI es una cadena de caracteres corta, que identifica inequívocamente un recurso y que tienen el siguiente formato

 <esquema>://<host>:puerto/<ruta><querystring><fragmento>

Esquema = Indican que protocolo hay que utilizar para usar el recurso ( http o https ) Host = Indica el lugar donde encontraremos el recurso ( por IP o por dominio ) Puerto = Puerto por donde se establece la conexión ( 80 o 443 )

Ruta = Ruta del recurso dentro del servidor, está separado por / queryStrng = Parámetros adicionales, separados por ? o por & Fragmento = Separado por #

(25)

Componentes de REST

URI (Uniform Resource Identifier)

• Las URI es el único medio por el que los clientes y servidores pueden realizar el intercambio de representaciones.

• Normalmente estos recursos son accesibles en una red o sistema.

• Para que un URI sea correcto, debe de cumplir los requisitos de formato, REST no indica de forma específica un formato obligatorio.

• Los URI asociados a los recursos pueden cambiar si modificamos el recurso (nombre, ubicación, características, etc)

Componentes de REST

Peticiones HTTP. Verbos

• HTTP dispone de un característica completamente REST y es que dispone de un interfaz uniforme para todos los recursos web.

• HTTP dispone de un conjunto cerrado de acciones (verbos) para gestionar todos los recursos.

Método HTTP Método REST Descripción

GET RETRIEVE Recuperar el estado de un recurso (HEAD + BODY) HEAD Recuperar el estado de un recurso (HEAD ) POST CREATE Creación de objetos

PUT UPDATE Actualizar o crear DELETE DELETE Eliminar un recurso

OPTIONS Recuperar los métodos HTTP que el servidor soporta para una URL específico

CONNECT TRACE PATCH

(26)

Tipos MIME

• Otro aspecto muy importante es la posibilidad de negociar distintos formatos (representaciones) a usar en la transferencia del estado entre servidor y cliente (y viceversa).

• La representación de los recursos es lo que se envía un lado a otro entre clientes y servidores.

• Como REST utiliza HTML, podemos transferir múltiples tipos de información.

• Los datos se transmiten a través de TCP/IP, el navegador sabe cómo interpretar las secuencias binarias (Content-Type) por el protocolo HTTP • La representación de un recurso depende del tipo de llamada que se ha

generado (Texto, HTML, PDF, etc).

Tipos MIME

• En HTTP cada uno de estos formatos son los diferentes Tipos MIME. • Cada tipo MIME tiene el formato de <tipo>/<subtipo>.

 application / json application / xml

 application / atom+xml application / javascript

 text / html audio / vorbis.

• ¿Cómo se negocia el tipo MIME entre el cliente y el servidor? • Es sencillo

 Petición

– En la cabecera ACCEPT envía una lista de tipos MIME que el cliente entiende.

– En caso de enviar contenido en el cuerpo, la cabecera CONTENT-TYPE indica en que formato MIME está codificado.

 Respuesta

– El servidor selecciona el tipo que más le interese de entre todos los especificados en la cabecera ACCEPT, y devuelve la respuesta indicando con la cabecera CONTENT-TYPE el formato del cuerpo.

• Si el servidor no entiende ninguno de los tipos MIME propuestos devuelve un mensaje con código 406 (incapaz de aceptar petición).

(27)

Tipos MIME

• La lista de tipos MIME se especifica en la cabecera (Accept) mediante lo que se llama una lista separada por comas de tipos (media range). • Cada uno de los tipos MIME puede ir acompañados por uno o más

parámetros, separados por ; text/html ; level=3

text/plain; charset=ISO-8859-1 application/json ; charset=UTF-8

• También pueden aparecer expresiones de rango, por ejemplo */* indica cualquier tipo MIME

image / * indica cualquier formato de imagen

• También se especifica la preferencia mediante q= text/*;q=0.3, text/html;q=0.7, text/html;level=1 a mayor numero mas preferencia

Códigos de Estado

• En HTTP el mensaje de respuesta contiene en su primera línea lo que se llama el código de estado, que indica el resultado de la operación. • Existen múltiples códigos, pero los mas utilizados son:

Código Descripción

200 OK, Indica éxito en la operación de forma genérica

201 Created, Indica que se creó con éxito un nuevo recurso web. Suele devolverse cuando ejecutamos un método POST o PUT

202 Accepted, Indica que la petición se ha aceptado pero que no está completa 204 No content, Indica éxito en la operación DELETE

301 Indica que el recurso se ha movido a otra URI de forma permanente 400 El mensaje de petición está mal formado

401 Requiere autenticación 403 Acceso denegado 404 Recurso no encontrado

(28)

Introducción a los Servicios REST

Servicio REST = CRUD de Web

• Son parecidos, pero existen algunas diferencias sutiles e importantes entre un CRUD simple y una arquitectura REST.

• El servicio REST puede soportar muchas representaciones de un mismo recurso:  xml, pdf, png, gif, excel, html, json, texto, etc.. Hay pocas BBDD que hagan esto.

• Habitualmente, las operaciones CRUD en Servicios REST no se reducen a persistir los datos, sino hacen mas cosas.

 Flujos de negocios, actualización de otros recursos, etc

• Los recursos tienen identificadores únicos por lo que se pueden interrelacionar con recursos en sistemas de terceros.

(29)

Diseño de un Servicio Web REST

• Para el desarrollo de los Servicios Web’s REST es necesario conocer una serie de cosas:

• Analizar el/los recurso/s a implementar • Diseñar la REPRESENTACION del recurso.

 Deberemos definir el formato de trabajo del recurso: XML, JSON, HTML, imagen, RSS, etc • Identificar el URI de acceso.

 Deberemos indicar el/los URI de acceso para el recurso • Conocer los métodos soportados por el servicio

 DELETE, GET, POST, PUT

• Qué códigos de estado pueden ser devueltos

 Los códigos de estado HTTP típicos que podrían ser devueltos

• Todo lo anterior dependerá de nuestro servicio a implementar.

Uso de la cabecera

• Request: Método /uri?parámetros • GET: Recupera el recurso

 Todos: Sin parámetros  Uno: Con parámetros • POST: Crea un nuevo recurso • PUT: Edita el recurso • DELETE: Elimina el recurso

• Accept: Indica al servidor el formato o posibles formatos esperados, utilizando MIME.

• Content-type: Indica en que formato está codificado el cuerpo, utilizando MIME

(30)

Peticiones

Request: GET /users Response: 200

content-type:application/json BODY

Request: GET /users/11 Response: 200

Request: POST /users BODY

Response: 201

Request: PUT /users BODY

Response: 200

Request: DELETE /users/11 Response: 204 no content

Jersey

• Jersey es una implementación para JAX-RS para la creación de Servicios Web’s REST.

• Jersey es un framework de código abierto, para entornos de producción y desarrollo (JSR 311 & JSR 339)

• Jersey nos permite hacer servicios web y que respondan al protocolo HTTP.

• Cuando utilizamos Jersey, éste actúa en nuestra aplicación como un servlet, que podemos configurar para aceptar peticiones, respuestas, etc. (en el web.xml) .

(31)

Servicio Web RESTful como un recurso JAX-RS

• Para crear nuestro Servicio Web, tendremos que crear un Proyecto Dinámico y configurarle para la ejecución y despliegue de Servicios Web.

( Servidor Aplicaciones –Tomcat, etc)

Servicio Web RESTful como un recurso JAX-RS

• Una vez creado el proyecto, necesitaremos descargar Jersey 1. Descargamos Jersey.

https://jersey.java.net/download.html ( jersey-archive-1.17.1.zip) 2. Lo descomprimimos en un directorio del disco

https://jersey.java.net/download.html ( jersey-archive-1.17.1.zip) c:\Download\jersey\...

(32)

Servicio Web RESTful como un recurso JAX-RS

3. Añadimos todos los ficheros *.jar del directorio LIB al proyecto en 2 sitios: WebContent– WEB-INF - Lib

Servicio Web RESTful como un recurso JAX-RS

• Después crearemos una clase que actuará de Servicio Web.

Si disponemos de Jboss TOOL podremos crear mas de un tipo 83

(33)

Servicio Web RESTful como un recurso JAX-RS

• Deberemos definir

Proyecto Dinámico donde crear el ServiceREST

Nombre del Servicio y la actualización del fichero web.xml

Definición de: - Paquete - Clase - Aplicación

Servicio Web RESTful como un recurso JAX-RS

• Si todo ha ido correcto nos ha tenido que crear 2 clases

AppHola: Clase para lanzar el Servicio en el Servidor ClaseHola: Clase que implementa el Servicio REST 85

(34)

Servicio Web RESTful como un recurso JAX-RS

• Sólo nos interesará la clase ClaseHola ANOTACIONES @Path( "/Saludo" )

- Define el PATH para acceder al Recurso - Puede existir un PATH para la Aplicación y uno por cada método

@GET()

- Indica el método HTML para utilizar el Recurso

@Produces (MediaType.TEXT) o @Produces ( "text/plain" ) - Nos indica el tipo de información que el método puede devolver.

Method.TEXT Method.XML Method.HTML

Servicio Web RESTful como un recurso JAX-RS

• Como Jersey crea un Servlet para dar servicio a este tipo de Servicios Web, necesitamos configurar correctamente también el fichero web.xml. 88

(35)

Servicio Web RESTful como un recurso JAX-RS

• Para acceder al URI correspondiente y probar nuestro servicio Web REST, necesitamos conocer como se crea esa URI:

http://<IP_Servidor>:Puerto/<Nombre_Proyecto>/<url-pattern>/<PATH>/<SubPATH> http://localhost:8080/RESTService / rest / Saludo

Servicio Web RESTful como un recurso JAX-RS

Fichero web.xml

<display-name>RESTService</display-name>

: <servlet>

<servlet-name>Jersey REST Service</servlet-name>

<servlet-class>com.sun.jersey.spi.container.servlet.ServletContainer</servlet-class> <init-param> <param-name>com.sun.jersey.config.property.packages</param-name> <param-value>servicio.web</param-value> </init-param> <load-on-startup>1</load-on-startup> </servlet> <servlet-mapping>

<url-pattern>/rest/*</url-pattern>

</servlet-mapping>

Nombre del Proyecto

Nombre del Paquete donde esta la clase

URL relativa de mapeo de la clase

(36)

Servicio Web RESTful como un recurso JAX-RS

• También podemos tener mas de un método en el Servicio REST como por ejemplo package servicio.web; import javax.ws.rs.Produces; import javax.ws.rs.GET; import javax.ws.rs.Path; @Path("/Saludo") public class ClaseHola {

@GET() @Path("/hola") @Produces("text/plain") public String saludar() {

return "Hola Mundo WS REST"; }

@GET() @Path("/adios") public String adios() {

return "Adios Mundo WS REST"; }

}

http://localhost:8080/RESTService / rest / Saludo / hola

http://localhost:8080/RESTService / rest / Saludo / adios

Anotaciones de RESTful

• Mediante anotaciones se puede extraer la información la petición: @GET

public String get(@Context UriInfo ui, @Context HttpHeaders hh) { MultivaluedMap<String, String> queryParams = ui.getQueryParameters(); MultivaluedMap<String, String> pathParams = ui.getPathParameters(); MultivaluedMap<String, String> headerParams = hh.getRequestHeaders(); Map<String, Cookie> pathParams = hh.getCookies();

}

• Con anotaciones se pueden mapear valores concretos a parámetros, pero los parámetros deben cumplir alguna de las siguientes condiciones:

1. Ser un tipo primitivo;

2. Tener un constructor que acepte un solo String como argumento;

3. Tener un método estático llamado valueOf o fromString que acepte un solo String como argumento;

4. Tener una implementación registrada de javax.ws.rs.ext.ParamConverterProviderSPI capaz de la conversión "a partir de una cadena" para el tipo.

5. Ser List<T>, Set<T> o SortedSet<T>, donde T satisface el 2 o el 3. La colección 92

(37)

Anotaciones de RESTful

@PathParam

• Esta anotación es una anotación a nivel de parámetro y sirve para ligar parámetros de una petición clásica REST con las variables del servicio como por ejemplo

/persona/nombre/pedro.

• En donde la variable nombre tiene asignado el valor de pedro. @GET

@Path("/persona/nombre/{nombre}")

public Persona buscarPersona( @PathParam("nombre") String nombre) {

Persona persona = null; for (Persona p : listaPersonas)

if (nombre.equals(p.getNombre())) {

persona = p; }

return persona;

} El datos es el nombre pasado en la URL al llamarlo

Anotaciones de RESTful

@QueryParam

• Esta anotación es una anotación útil ya que nos permite leer parámetros que vengan a través de una petición clásica GET con paso de parámetros

@GET

@Path("/persona")

public Persona buscarPersonaClasico( @QueryParam("nombre") String nombre)

{

Persona persona = null; for (Persona p : listaPersonas)

if (nombre.equals(p.getNombre())) { persona = p; } return persona; } 94

(38)

Anotaciones de RESTful

@FormParam

• Esta anotación es una anotación a nivel de parámetro y sirve para ligar parámetros de un formulario HTML con variables del servicio REST .

• Utilizado cuando queremos que los valores de un formulario pasen como parámetros a un método determinado.

@POST

@Path("/persona/add") public void addPersona(

@FormParam("nombre") String nombre, @FormParam("apellidos") String apellidos)

{

Persona p = new Persona(nombre, apellidos); listaPersonas.add(p);

}

Los datos son pasados desde un FORMULARIO

Anotaciones de RESTful

• @MatrixParam extrae información de los segmentos de ruta de URL. • @HeaderParam extrae información de los encabezados HTTP. • @CookieParam extrae información de las cookies recibidas en los

encabezados HTTP.

public Response getCookie(@CookieParam("name") Cookie cookie) { • @Context devuelve todo el contexto del objeto.

public Response getPeticion(@Context HttpServletRequest request) { • Para evitar el valor nulo en los parámetros cuando no existan en la

petición se pueden establecer valores por defecto: @GET

public Response list(

@DefaultValue("0") @QueryParam("page") int page, @DefaultValue("20") @QueryParam("step") int step, 96

(39)

Preparar respuesta

• A veces es necesario devolver información adicional en respuesta a una solicitud HTTP.

• Dicha información se puede generar y devolver utilizando Response y Response.ResponseBuilder.

• Por ejemplo, un patrón RESTful común para la creación de un nuevo recurso es utilizar una solicitud POST que devuelve un código de estado 201 (Creado) y un encabezado Location cuyo valor es el URI para el recurso recién creado.

@POST

@Consumes("application/json")

public javax.ws.rs.core.Response post(String content) { URI createdUri = ...

create(content);

return Response.status(201).created(createdUri).build(); }

Excepciones

• Es posible utilizar el mismo mecanismo de preparar respuestas para devolver errores HTTP directamente, por ejemplo, al manejar excepciones en un bloque try-catch.

Response.status(Responses.NOT_FOUND) .entity("Not Found").type("text/plain").build()

• Es recomendable usar el sistema de excepciones con la excepción

WebApplicationException o uno de sus herederos. • throw new WebApplicationException(404);

• throw new WebApplicationException(404, "Not Found");

• Las excepciones que no se intercepten generaran un código de error

500: Error interno de servidor. 98

(40)

Registro: Explicito

Fichero web.xml <servlet> <servlet-name>servicio.web.App</servlet-name> </servlet> <servlet-mapping> <servlet-name>servicio.web.App</servlet-name> <url-pattern>/ws/*</url-pattern> </servlet-mapping> Fichero App.java package servicio.web; import javax.ws.rs.core.Application; import java.util.HashSet; import java.util.Set;

public class App extends Application { @Override

public Set<Class<?>> getClasses() {

HashSet<Class<?>> classes = new HashSet<Class<?>>(); classes.add(Service1.class); classes.add(Service2.class); // … return classes; } }

Registro: Descubrimiento

Fichero web.xml <servlet>

<servlet-class>com.sun.jersey.spi.container.servlet.ServletContainer</servlet-class> <init-param> <param-name>com.sun.jersey.config.property.packages</param-name> <param-value>servicios.rest</param-value> </init-param> <load-on-startup>1</load-on-startup> </servlet> Fichero App.java package servicios.rest; import javax.ws.rs.ApplicationPath; import javax.ws.rs.core.Application; @ApplicationPath("/api")

public class RestApplication extends Application { }

(41)

Servicio Web RESTful

import javax.ws.rs.Consumes; import javax.ws.rs.DELETE; import javax.ws.rs.GET; import javax.ws.rs.POST; import javax.ws.rs.PUT; import javax.ws.rs.Path; import javax.ws.rs.PathParam; import javax.ws.rs.Produces; import javax.ws.rs.core.MediaType; import javax.ws.rs.InternalServerErrorException; @Path("/personas") @Consumes(MediaType.APPLICATION_JSON) @Produces(MediaType.APPLICATION_JSON) public class Personas {

@GET

@Produces(MediaType.APPLICATION_JSON) public Persona[] getAll() {

return…; }

@GET @Path("{id: \\d+}")

@Produces(MediaType.APPLICATION_JSON) public Persona get(@PathParam("id") final int id) {

Servicio Web RESTful

@GET @Path("{id: \\d+}")

@Produces(MediaType.APPLICATION_JSON) public Persona get(@PathParam("id") final int id) {

if(lst.get(id) == null)

throw new InternalServerErrorException("No existe"); return…;

} @POST

@Produces(MediaType.APPLICATION_JSON) public Persona insert(final Persona persona) {

… } @PUT

@Produces(MediaType.APPLICATION_JSON) public Persona update(final Persona persona) {

… } @DELETE @Path("{id: \\d+}") @Produces(MediaType.APPLICATION_JSON) 104

(42)

Seguridad

• La ejecución de aplicaciones JavaScript puede suponer un riesgo para el usuario que permite su ejecución.

• Por este motivo, los navegadores restringen la ejecución de todo código JavaScript a un entorno de ejecución limitado.

• Las aplicaciones JavaScript no pueden establecer conexiones de red con dominios distintos al dominio en el que se aloja la aplicación JavaScript. • Los navegadores emplean un método estricto para diferenciar entre dos

dominios ya que no permiten ni subdominios ni otros protocolos ni otros puertos.

• Si el código JavaScript se descarga desde la siguiente URL: http://www.ejemplo.com

• Las funciones y métodos incluidos en ese código no pueden acceder a: • https://www.ejemplo.com/scripts/codigo2.js

• http://www.ejemplo.com:8080/scripts/codigo2.js • http://scripts.ejemplo.com/codigo2.js

• http://192.168.0.1/scripts/codigo2.js

CORS

• Un recurso hace una solicitud HTTP de origen cruzado cuando solicita otro recurso de un dominio distinto al que pertenece.

• XMLHttpRequest sigue la política de mismo-origen, por lo que, una aplicación usando XMLHttpRequest solo puede hacer solicitudes HTTP a su propio dominio. Para mejorar las aplicaciones web, los

desarrolladores pidieron a los proveedores de navegadores que permitieran a XMLHttpRequest realizar solicitudes de dominio cruzado. • El Grupo de Trabajo de Aplicaciones Web del W3C recomienda el nuevo

mecanismo de Intercambio de Recursos de Origen Cruzado (CORS, Cross-origin resource sharing: https://www.w3.org/TR/cors). Los servidores deben indicar al navegador mediante cabeceras si aceptan peticiones cruzadas y con que características:

 "Access-Control-Allow-Origin", "*"

 "Access-Control-Allow-Headers", "Origin, Content-Type, Accept, Authorization,

X-XSRF-TOKEN"

 "Access-Control-Allow-Methods", "GET, POST, PUT, DELETE, OPTIONS"  "Access-Control-Allow-Credentials", "true"

• Soporte: Chrome 3+ Firefox 3.5+ Opera 12+ Safari 4+ Internet Explorer 106

(43)

Filtro con cabeceras CORS

@Provider

public class CORSHeadersFilter implements ContainerResponseFilter { @Override

public void filter(ContainerRequestContext request,

ContainerResponseContext response) throws IOException { String origin = request.getHeaders().getFirst("Origin");

response.getHeaders().add("Access-Control-Allow-Origin", origin); // response.getHeaders().add("Access-Control-Allow-Origin", "*"); response.getHeaders().add("Access-Control-Allow-Headers",

"origin, content-type, accept, authorization");

response.getHeaders().add("Access-Control-Allow-Credentials","true"); response.getHeaders().add("Access-Control-Allow-Methods",

"GET, POST, PUT, DELETE, OPTIONS, HEAD"); }

}

APLICACIONES CLIENTES DE UN

SERVICIO WEB REST

(44)

Introducción a los clientes WS RESTful

• Dependiendo del entorno en que trabajamos, podemos elegir entre varias opciones del cliente.

• Nuestro cliente puede ser:

• Una aplicación de línea de comandos • Una aplicación GUI Swing

• o una aplicación web.

• Podemos disponer de varios clientes para consumir diferentes tipos de representación.

• Por ejemplo:

 Aplicación de línea de comando en una secuencia XML formateada .

 Aplicación Swing, mostraremos el resultado en un formato más fácil de leer y vamos a crear un cliente de GUI reutilizable.

 En JSP, podremos utilizar RSS y el navegador web para mostrar los resultados .

Introducción a los clientes WS RESTful

• Hay muchos servicios RESTful disponibles en Internet de distribuidores conocidos como Yahoo!, Amazon y eBay.

• Algunos de estos Servicios REST están disponibles para poder conectarnos/probar nuestros clientes REST.

• Ejemplos

• Servicios de Noticias de Yahoo

 Servicio de noticias HTML que nos devuelve información sobre el tema pedido.  Utiliza peticiones HTTP GET

• Amazon E-Commerce

 Servicio de e-commerce, para hacer compras de libros, informática, etc  Utiliza peticiones HTTP GET

• Tumblr

 Es una variación del blog tradicional, que hace hincapié en las entradas de texto cortos con multimedia To d o s n e ce si ta n C U E N TA d e U su a rio 112

(45)

Funcionamiento de un Cliente WS REST

• La petición de un cliente WS REST es muy simple, sólo debemos conocer el la URI del Servicio REST.

• Etapas:

1. Localizar el WS REST

2. Creación de una instancia del URI del WS. 3. Apertura de una conexión con el WS 4. Realización de la llamada al método deseado. 5. Obtener la respuesta y tratarla

Funcionamiento de un Cliente WS REST

Formulario HTML como CLIENTE REST.

• Podemos tener un Web Servicio REST, que esté preparado para recibir parámetros desde un formulario.

@FormParam

• Nos bastaría hacer un formulario HTML para poder llamar al Servicio Web y que éste nos contestara.

• No necesitamos obtener una conexión con el Servicios, sólo utilizarlo y ya. • Este tipo de Servicios:

 Trabajan con Métodos HTML POST

 Están preparados para devolver código HTML y ser interpretado por el Navegador. 114

(46)

Funcionamiento de un Cliente WS REST

Formulario HTML como CLIENTE REST. <html>

<head>

</head> <body>

<p>This page uses frames. The current browser you are using does not support frames.</p>

<form action="http://localhost:8081/RESTService/rest/Saludo/bienvenido" method="post"> <input type="text" name="nombre">

<input type="text" name="apellido">

</body> </html>

Funcionamiento de un Cliente WS REST

CLIENTE REST con representación XML

• Deberemos crear una instancia URI con el Web Service y realizar una conexión del él.

• Esta representación se trata como un Flujo de Caracteres (InputStream) que serán encapsulados en elementos BufferReaders.

BufferedReader in = new BufferedReader(new InputStreamReader ( tc.getInputStream() ) );

• Su resultado podemos mostrarlo en pantalla o derivarlo a algún fichero para su tratamiento XML.

(47)

Funcionamiento de un Cliente WS REST

CLIENTE REST con representación XML

public class RESTClient {

public static void main(String[] args) { try {

URL twitter = new URL("http://maps.googleapis.com/maps/api/distancematrix/xml?& mode=driving&sensor=false&origins=Madrid&destinations=Barcelona"); URLConnection tc = twitter.openConnection();

BufferedReader in = new BufferedReader(new InputStreamReader ( tc.getInputStream() ) ); String line;

while ((line = in.readLine()) != null) { System.out.println(line); } in.close(); } catch (MalformedURLException e) { e.printStackTrace(); } catch (IOException e) { e.printStackTrace(); } } }

Funcionamiento de un Cliente WS REST

RESULTADO <application/xml; charset=UTF-8 <?xml version="1.0" encoding="UTF-8"?> <DistanceMatrixResponse> <status>OK</status> <origin_address>Madrid, Spain</origin_address> <destination_address>Barcelona, Spain</destination_address> <row> <element> <status>OK</status> <duration> <value>20162</value> <text>5 hours 36 mins</text> </duration> <distance> <value>621213</value> <text>621 km</text> </distance> </element> </row> </DistanceMatrixResponse> : 118

(48)

Funcionamiento de un Cliente WS REST

CLIENTE REST con representación RSS

• Podemos utilizar el mismo recurso, pero con otra representación. • Ahora utilizaremos RSS para la obtención de los datos

• Utilizaremos el URI: http://twitter.com/statuses/public_timeline.rss • Utilizaremos el navegador FireFox para mostrar el resultado de la petición

realizada.

• El cliente lo implementaremos con un JSP.

Funcionamiento de un Cliente WS REST

CLIENTE REST con representación RSS

<%@ page contentType="text/xml; charset=UTF-8" %> <%@ page import="java.io.BufferedReader, java.io.IOException,

java.io.InputStreamReader, java.net.MalformedURLException, java.net.URL, java.net.URLConnection" %> <%

try {

URL twitter = new URL("http://www.redesparalaciencia.com/redes.rss"); URLConnection tc = twitter.openConnection();

BufferedReader in = new BufferedReader(new InputStreamReader(tc.getInputStream())); String line;

while ((line = in.readLine()) != null) { out.println(line); } in.close(); } catch (MalformedURLException e) { e.printStackTrace(); } catch (IOException e) { e.printStackTrace(); } %> Cliente.jsp

Para probar el ejemplo, debemos copiar el fichero al directorio /webapps/ de TOMCAT O crear un Proyecto Dinamico y JSP

(49)

Funcionamiento de un Cliente WS REST

CLIENTE REST con representación HTML

• También podemos obtener la representación de un recurso en formato HTML.

• Podemos utilizar un servlet para ejecutar una parte de código y devolver un resultado HTML.

• También podemos obtener el recurso en XML y convertirlo a HTML. • Las peticiones al recurso serían similares a las anteriores.

(50)

Funcionamiento de un Cliente WS REST

CLIENTE REST con representación HTML

public class RESTfulServletClient extends HttpServlet {

public void doGet(HttpServletRequest req,HttpServletResponse res) { // Set mime-type res.setContentType("image/jpeg"); BufferedReader in = null; try { : :

// Conectando con la API de Twitter

URL twitter = new URL("https://dev.twitter.com/docs/api/1/get/users/lookup"); URLConnection tc = twitter.openConnection();

in = new BufferedReader(new InputStreamReader(tc.getInputStream())); String line; : : } Servlet

JSON

JavaScript Object Notation http://tools.ietf.org/html/rfc4627 124

(51)

Introducción

• JSON (JavaScript Object Notation) es un formato sencillo para el

intercambio de información.

• El formato JSON permite representar estructuras de datos (arrays) y

objetos (arrays asociativos) en forma de texto.

• La notación de objetos mediante JSON es una de las características

principales de JavaScript y es un mecanismo definido en los

fundamentos básicos del lenguaje.

• En los últimos años, JSON se ha convertido en una alternativa al

formato XML, ya que es más fácil de leer y escribir, además de ser

mucho más conciso.

• No obstante, XML es superior técnicamente porque es un lenguaje

de marcado, mientras que JSON es simplemente un formato para

intercambiar datos.

• La especificación completa del JSON es la RFC 4627, su tipo MIME

oficial es application/json y la extensión recomendada es .json.

Estructuras

• JSON está constituido por dos estructuras:

– Una colección de pares de nombre/valor. En los lenguajes

esto es conocido como un objeto, registro, estructura,

diccionario, tabla hash, lista de claves o un arreglo

asociativo.

– Una lista ordenada de valores. En la mayoría de los

lenguajes, esto se implementa como tablas, arreglos,

vectores, listas o secuencias.

• Estas son estructuras universales; virtualmente todos

los lenguajes de programación las soportan de una

forma u otra. Es razonable que un formato de

intercambio de datos que es independiente del

lenguaje de programación se base en estas estructuras.

(52)

Sintaxis

• Un array es un conjunto de valores separados por comas (,)

que se encierran entre corchetes [ … ]

• Un objeto es un conjunto de pares nombre:valor

separados por comas (,) que se acotan entre llaves { … }

• Los nombre son cadenas, entre comillas dobles (").

• El separador entre el nombre y el valor son los dos puntos

(:)

• El valor debe ser un objeto, un array, un número, una

cadena o uno de los tres nombres literales siguientes (en

minúsculas):

– true, false o null

• Se codifica en Unicode, la codificación predeterminada es

UTF-8.

Valores numéricos

• La representación de números es similar a la utilizada en la mayoría

de los lenguajes de programación.

• Un número contiene una parte entera que puede ser prefijada con

un signo menos opcional, que puede ser seguida por una parte

fraccionaria y / o una parte exponencial.

• La parte fraccionaria comienza con un punto (como separador

decimal) seguido de uno o más dígitos.

• La parte exponencial comienza con la letra E en mayúsculas o

minúsculas, lo que puede ser seguido por un signo más o menos, y

son seguidas por uno o más dígitos.

• Los formatos octales y hexadecimales no están permitidos. Los

ceros iniciales no están permitidos.

• No se permiten valores numéricos que no se puedan representar

como secuencias de dígitos (como infinito y NaN).

(53)

Valores cadena

• La representación de las cadenas es similar a las convenciones

utilizadas en la familia C de lenguajes de programación.

• Una cadena comienza y termina con comillas (").

• Se pueden utilizar todos los caracteres Unicode dentro de las

comillas con excepción de los caracteres que se deben escapar: los

caracteres de control (U + 0000 a U + 001F) y los caracteres con

significado.

• Cuando un carácter se encuentra fuera del plano multilingüe básico

(U + 0000 a U + FFFF), puede ser representado por su

correspondiente valor hexadecimal. Las letras hexadecimales A-F

puede ir en mayúsculas o en minúsculas.

• Secuencias de escape:

– \\, \/, \", \n, \r, \b, \f, \t – \u[0-9A-Fa-f]{4}

Objeto con anidamientos

{

"Image": {

"Width": 800,

"Height": 600,

"Title": "View from 15th Floor",

"Thumbnail": {

"Url": "/image/481989943",

"Height": 125,

"Width": "100"

},

"IDs": [116, 943, 234, 38793]

}

131

(54)

Array de objetos

[ { "precision": "zip", "Latitude": 37.7668, "Longitude": -122.3959, "City": "SAN FRANCISCO", "State": "CA", "Zip": "94107" }, { "precision": "zip", "Latitude": 37.371991, "Longitude": -122.026020, "City": "SUNNYVALE", "State": "CA", "Zip": "94085" } ]

JSON en JavaScript

• El Standard Built-in ECMAScript Objects define que todo

interprete de JavaScript debe contar con un objeto JSON

como miembro del objeto Global.

• El objeto debe contener, al menos, los siguientes miembros:

– JSON.parse (Función): Convierte una cadena de la notación de objetos de JavaScript (JSON) en un objeto de JavaScript.

– JSON.stringify (Función): Convierte un valor de JavaScript en una cadena de la notación de objetos JavaScript (JSON).

(55)

Patrón Agregado (Aggregate)

• Una Agregación es un grupo de objetos asociados que deben tratarse como una unidad a la hora de manipular sus datos.

• El patrón Agregado es ampliamente utilizado en los modelos de datos basados en Diseños Orientados al Dominio (DDD).

• Proporciona un forma de encapsular nuestras entidades y los accesos y relaciones que se establecen entre las mismas de manera que se simplifique la complejidad del sistema en la medida de lo posible. • Cada Agregación cuenta con una Entidad Raíz (root) y una Frontera

(boundary):

– La Entidad Raíz es una Entidad contenida en la Agregación de la que colgarán el resto de entidades del agregado y será el único punto de entrada a la Agregación.

– La Frontera define qué está dentro de la Agregación y qué no.

• La Agregación es la unidad de persistencia, se recupera toda y se almacena toda.

ASYNCHRONOUS JAVASCRIPT AND

XML

(56)

Introducción

• Una aplicación Web típica recogerá datos del usuario

(primer nivel), los enviará al servidor, que ejecutará un

programa (segundo y tercer nivel) y cuyo resultado

será formateado y presentado al usuario en el

navegador (primer nivel otra vez).

Introducción

• AJAX, acrónimo de Asynchronous JavaScript And XML (JavaScript asíncrono y XML), es una técnica de desarrollo web para crear aplicaciones interactivas o RIA (Rich Internet Applications). Estas aplicaciones se ejecutan en el cliente, es decir, en el navegador de los usuarios mientras se mantiene la comunicación asíncrona con el servidor en segundo plano. De esta forma es posible realizar cambios sobre las páginas sin necesidad de recargarlas, mejorando la interactividad, velocidad y usabilidad en las aplicaciones.

• Ajax es una tecnología asíncrona, en el sentido de que los datos adicionales se solicitan al servidor y se cargan en segundo plano sin interferir con la visualización ni el comportamiento de la página. Ajax no constituye una tecnología en sí, sino que es un término que engloba a un grupo de éstas que trabajan conjuntamente. • JavaScript es el lenguaje interpretado (scripting language) en el que normalmente

se efectúan las funciones de llamada de Ajax mientras que el acceso a los datos se realiza mediante XMLHttpRequest, objeto disponible en los navegadores actuales. En cualquier caso, no es necesario que el contenido asíncrono esté formateado en XML.

• Ajax es una técnica válida para múltiples plataformas y utilizable en muchos sistemas operativos y navegadores dado que está basado en estándares abiertos como JavaScript y Document Object Model (DOM).

(57)

XMLHttpRequest

• XMLHttpRequest (XHR), también conocido como XMLHTTP (Extensible Markup

Language / Hypertext Transfer Protocol), es una interfaz empleada para realizar peticiones HTTP y HTTPS a servidores Web.

• Para los datos transferidos se usa cualquier codificación basada en texto, incluyendo: texto plano, XML, JSON, HTML y codificaciones particulares específicas.

• El navegador implementa la interfaz como una clase de la que una aplicación cliente puede generar tantas instancias como necesite y permita el navegador para manejar el diálogo con el servidor.

• La primera versión de la interfaz XMLHttpRequest fue desarrollada por Microsoft que la introdujo en la versión 5.0 de Internet Explorer utilizando un objeto ActiveX. A partir de la versión 7 la interfaz se ofrece de manera integrada.

• El proyecto Mozilla incorporó la primera implementación integrada en la versión 1.0 de la Suite Mozilla en 2002. Esta implementación sería seguida por Apple a partir de Safari 1.2, Opera Software a partir del Opera 8.0 e iCab desde la versión 3.0b352.

• El World Wide Web Consortium presentó el 27 de septiembre de 2006 el primer borrador de una especificación estándar de la interfaz.

Propiedades

Propiedad Descripción

readyState

0 No inicializado (objeto creado, pero no se ha invocado el método open) 1 Cargando (objeto creado, pero no se ha invocado el método send) 2 Cargado (se ha invocado el método send, pero el servidor aún no ha

respondido)

3 Interactivo (descargando, se han recibido algunos datos, aunque no se puede _{emplear la propiedad responseText)} 4 Completo (se han recibido todos los datos de la respuesta del servidor) responseText El contenido de la respuesta del servidor en forma de cadena de texto

responseXML El contenido de la respuesta del servidor en formato XML. El objeto devuelto se puede _{procesar como un objeto DOM} status El código de estado HTTP devuelto por el servidor (200 para una respuesta correcta,

404 para "No encontrado", 500 para un error de servidor, etc.)

El código de estado HTTP devuelto por el servidor en forma de cadena de texto: "OK", 139

(58)

Métodos y eventos

Método Descripción

abort() Detiene la petición actual.

getAllResponseHeaders() Devuelve una cadena de texto con todas las cabeceras de la respuesta del servidor.

getResponseHeader("cabecera") Devuelve una cadena de texto con el contenido de la cabecera solicitada.

open("metodo", "url")

Establece los parámetros de la petición que se realiza al servidor. Los parámetros necesarios son el método HTTP empleado y la URL destino.

send(contenido) Realiza la petición HTTP al servidor

setRequestHeader("cabecera", "valor")

Permite establecer cabeceras personalizadas en la petición HTTP. Se debe invocar entre el open() y el send().

onreadystatechange Evento. Se invoca cada vez que se produce un cambio en el estado de la petición HTTP.

Códigos HTTP (status)

status statusText Descripción

100 Continue Una parte de la petición (normalmente la primera) se ha recibido sin problemas y se puede enviar el resto de la petición

101 Switching protocols

El servidor va a cambiar el protocolo con el que se envía la información de la respuesta. En la cabecera Upgrade indica el nuevo protocolo

200 OK La petición se ha recibido correctamente y se está enviando la respuesta. Este código es con mucha diferencia el que mas devuelven los servidores

201 Created Se ha creado un nuevo recurso (por ejemplo una página web o un archivo) como parte de la respuesta

202 Accepted La petición se ha recibido correctamente y se va a responder, pero no de forma _inmediata 203 Non-Authoritative

Information

La respuesta que se envía la ha generado un servidor externo. A efectos prácticos, es muy parecido al código 200

204 No Content La petición se ha recibido de forma correcta pero no es necesaria una respuesta 205 Reset Content El servidor solicita al navegador que inicialice el documento desde el que se realizó la

petición, como por ejemplo un formulario

206 Partial Content La respuesta contiene sólo la parte concreta del documento que se ha solicitado en la petición

(59)

Códigos de redirección

300 Multiple Choices

El contenido original ha cambiado de sitio y se devuelve una lista con varias direcciones alternativas en las que se puede encontrar el contenido

301 Moved Permanently

El contenido original ha cambiado de sitio y el servidor devuelve la nueva URL del contenido. La próxima vez que solicite el contenido, el navegador utiliza la nueva URL

302 Found El contenido original ha cambiado de sitio de forma temporal. El servidor devuelve la nueva URL, pero el navegador debe seguir utilizando la URL original en las próximas peticiones 303 See Other El contenido solicitado se puede obtener en la URL alternativa devuelta por el servidor. Este

código no implica que el contenido original ha cambiado de sitio

304 Not Modified

Normalmente, el navegador guarda en su caché los contenidos accedidos frecuentemente. Cuando el navegador solicita esos contenidos, incluye la condición de que no hayan cambiado desde la última vez que los recibió. Si el contenido no ha cambiado, el servidor devuelve este código para indicar que la respuesta sería la misma que la última vez 305 Use Proxy El recurso solicitado sólo se puede obtener a través de un proxy, cuyos datos se incluyen en

la respuesta 307 Temporary

Redirect

Se trata de un código muy similar al 302, ya que indica que el recurso solicitado se encuentra de forma temporal en otra URL

Códigos de error del navegador

400 Bad Request El servidor no entiende la petición porque no ha sido creada de forma correcta

401 Unauthorized El recurso solicitado requiere autorización previa

402 Payment Required Código reservado para su uso futuro

403 Forbidden No se puede acceder al recurso solicitado por falta de permisos o porque el usuario y contraseña indicados no son correctos

404 Not Found El recurso solicitado no se encuentra en la URL indicada. Se trata de uno de los códigos más utilizados y responsable de los típicos errores de Página no encontrada

405 Method Not Allowed

El servidor no permite el uso del método utilizado por la petición, por ejemplo por utilizar el método GET cuando el servidor sólo permite el método POST

406 Not Acceptable El tipo de contenido solicitado por el navegador no se encuentra entre la lista de tipos de contenidos que admite, por lo que no se envía en la respuesta

407 Proxy Authentication Required

Similar al código 401, indica que el navegador debe obtener autorización del proxy antes de que se le pueda enviar el contenido solicitado

408 Request Timeout El navegador ha tardado demasiado tiempo en realizar la petición, por lo que el servidor la descarta