Servicios Web

Conceptos sobre soap y rest

1. 1

2. Web Service
René Guamán-Quinche
Facultad de la Energía, las Industrias y los Recursos Naturales No Renovables
Carrera de Ingeniería en Sistemas/Computación
Enero 2021
Loja, Ecuador

3. 3
DEFINICIÓN

4. 4

Son aplicaciones distribuidas que se basan en una serie de estándares y
protocolos para intercambiar información

Distintas aplicaciones de software desarrolladas en lenguajes de
programación diferentes y ejecutadas sobre plataformas pueden utilizar los
WS para intercambiar información en redes de computadora
DEFINICIÓN

5. 5

Expone un conjunto de servicios para ser consumidos a través de la red

Especifica un conjunto de operaciones (funciones que retornan
determinado valor , reciben un conjunto finito de parámetros, y retorna un
resultado), a través de una url, donde una aplicación Cliente remota los
puede consumir(podría haber cuestiones de seguridad en el medio)
DEFINICIÓN

6. 6

Un SW es un componente de software que se comunica con otras aplicaciones
codificando los mensajes en XML y enviando estos mensajes a través de
protocolos estándares de Internet tales como el Hypertext Transfer Protocol
(HTTP)
DEFINICIÓN

7. 7
Un SW es similar a un sitio web que no cuenta con un interfaz de usuario y que da servicio a
las aplicaciones en lugar de a las personas y, en vez de obtener solicitudes desde el navegador y
retornar páginas web como respuesta, recibe solicitudes a través de un mensaje formateado en
XML desde una aplicación, realiza una tarea y devuelve un mensaje de respuesta también en
formato XML.
DEFINICIÓN

8. 8

Capa de datos: almacena información requerida por el servicio Web.

Capa de acceso a datos: presenta una vista lógica de los datos físicos a la capa de
negocios, aísla la lógica de negocios de los cambios realizados a los almacenes de
datos y garantiza la integridad de los datos
Arquitectura

9. 9

Capa de negocios: Implementa la lógica de negocios del servicio Web.

La Lógica Empresarial: Proporciona una interfaz sencilla que se asigna a las
operaciones expuestas por el servicio Web
Arquitectura

10. 10

El agente de escucha: Recibe los mensajes entrantes que contienen solicitudes de
servicios, analiza los mensajes y envía la solicitud al método apropiado en la capa
de negocios. Si el servicio devuelve una respuesta, el agente de escucha
empaqueta la respuesta de la capa de negocios es un mensaje y su envío al cliente
Arquitectura

11. 11

12. 12
SOAP
Arquitectura de web services basado en
soap

13. 13

Cuando se expone un servicio web, se publica un archivo wsdl (Web
Services Description Language) en el servidor web, donde se muestran
esas operación, parámetros, tipos de retorno, dirección para invocar el
servicio, etc.

Otro diseño de SW, denominado Restful, donde, resumidamente, en vez
de publicar operaciones, se publican identificadores de recursos, para
poder accederlos de forma remota
SOAP

14. 14

SW es una colección de protocolos abiertos y estándares usados para el
intercambio de datos entre aplicaciones o sistemas

Software ejecutándose en distintas plataformas, y escritos en distintos lenguajes
de programación a través del uso de estos protocolos estándares se comunican
entre si

SOAP - Simple Object Access Protocol

WSDL - Web Services Description Language

UDDI - Universal Description, Discovery and Integration

WS-Security

WS-ReliableMessaging

WS-Reliability

WS-Addressing
SOAP – Especificaciones

15. 15

La plataforma básica de los servidores es XML + HTTP

Todos los servicios web estándar utilizan los siguientes componentes:

SOAP (Simple Object Access Protocol)

UDDI (Universal Description, Discovery and Integration)

WSDL (Web Services Description Language)
SOAP – Componentes

16. 16
SOAP – Componentes
XML: formato estándar para intercambio de datos
SOAP (Simple Object Access Protocol): Protocolo sobre el cual se establece el intercambio de
datos
WSDL (Web Services Description Language): Es una descripción basada en XML de los
requisitos funcionales necesarios para establecer una comunicación con los servicios Web
UDDI (Universal Description Discovery and Integration): Registro público para almacenar de
forma estructurada información sobre empresas y servicios que estas ofrecen
WS-Security (Web Service Security): Permite optimizar la seguridad de los servicios web
mediante algoritmos de encriptación

17. 17
SOAP

Se trata de un protocolo de comunicación basado en XML

Permite establecer la forma de comunicación entre las aplicaciones que publican o
consumen "Web services"

SOAP especifica el formato de los mensajes

Es independiente de la plataforma y lenguaje de programación

El mensaje SOAP está compuesto por un Envelope (sobre), cuya estructura está
formada por los siguientes elementos Header (cabecera) y Body (cuerpo)

18. 18
SOAP – Componentes

19. 19
SOAP – Componentes

20. 20
WSDL Web Services Description Language

Permite que un servicio y un cliente establezcan un acuerdo en lo que se refiere
a los detalles de transporte de mensajes y su contenido, a través de un
documento procesable por dispositivos

Representa una especie de contrato entre el proveedor del servicio y el que lo
solicita

Especifíca la sintaxis y los mecanismos de intercambio de mensajes

Es un documento XML que describe un conjunto de mensajes SOAP y cómo se
realiza el intercambio de mensajes

21. 21

22. 22
REST

Es una técnica de arquitectura software para sistemas hipermedia distribuidos
como la World Wide World

Rest no es un servicio web ni una tecnología

Son aquellos servicios web que cumplen con los principios de REST

23. 23
REST

24. 24
REST

Está compuesto por una colección de principios de arquitectura de software para
construir sistemas distribuidos basados en mecanismos que definen y acceden a
recursos como internte

REST ofrece un estilo simple, interoperable y flexible de construir "Web
Services" sin adherise a una tecnología en particular

El término REST es muchas veces empleado para describir un estilo de
transmisión de datos basado en HTTP sin agrega capas semánticas ni de manejo
de sesiones

25. 25
REST

HTTP (HyperText Tranfer Protocol): protocolo de comunicación utilizado para
intercambiar información

REST (Representation State Transfer): estilo arquitectónico de software
basado principalmente en HTTP para transferencia de hypermedia en sistemas
distribuidos

URI (Uniform Resource Identifier): identifacador uniforme o dirección para
acceder a las representación de un recurso

Ejemplo: http://aprendejava.es/?pagina=2#inicio

MIME Types (Multiple Internet Mail Extension): identificador compuesto de
2 partes que describe el formato de un recurso en internet

Ejemplos: application/xml, application/json

26. 26
Características

Sin estado: cada mensaje HTTP contiene toda la información necesaria

Operaciones HTTP: Uso de POST, GET, PUT, DELETE y otros

Sintaxis universal - URI: Cada recurso queda identificado por su URI

Hipermedios: Relación entre recursos mediante hipervínculos

Códigos de estado HTTP: Uso los código HTTP para indicar el resultado de la
petición

27. 27
Características

Sin estado

Sin sesiones ni cookies

Cada petición es independiente

Cada petición debe tener toda la información necesaria para que el servidor la
entienda y devuelva la respuesta correcta

28. 28
Operaciones REST
Utiliza los métodos HTTP de forma
explicita para los operadores a realizar:

GET: obtener un recurso del servidor

POST: crear un recurso en el servidor

PUT: actualizar un recurso del servidor

DELETE: eliminar un recurso del
servidor

Hay más métodos, pero estos son los más
frecuentes CRUD
GET /clientes Nos permite acceder al listado de clientes
GET /clientes/12 Nos permite acceder al detalle del cliente con id
12
POST /clientes Permite crear un cliente nuevo. Se envía el la
petición la información que se necesita para la creación (mediante
JSON y XML)
<usuario>
<nombre>René</nombre>
<apellido>René</apellidos>
</usuario>
PUT /clientes/12 Permite editar el cliente con el id 12. Al igual
que el POST se pasan los datos necesarios con cuerpo de petición
<usuario>
<apellido>René</apellidos>
</usuario>
DELETE /clientes/12 Eliminar el cliente con el id 12

29. 29
Operaciones REST

30. 30
Operaciones REST

31. 31
Operaciones REST

32. 32
Operaciones REST

33. 33
Operaciones REST

34. 34
Operaciones REST

35. 35
Operaciones REST

36. 36
Características

Sintaxis Universal

Cada recurso se identifica con su URI única

Nombres mejor que verbos (excepto cuando son operaciones)

Nombres mejor en plural: http://_______/usuarios

Normalmente dos URLs similares: para listado (collection) y para ítem

Versión de la API en la URL

CRUD a través de su URI y una operación HTTP

37. 37
Características

Hipermedia

HETAOAS: Hypermedia As The Engine Of Application State

Una respuesta debe ofrecer toda la información necesaria

Dado un punto de entrada a la API REST, es posible descubrir todos sus recursos a
partir sólo de las respuestas del servidor. La respuesta devuelta por el servidor
puede contener hipervínculos a otros recursos
{
”id”: 12,
”nombres”: “René”,
”apellidos”: “Guamán”,
”dispositivos”: [
{“id”: 1033},
{“id”: 3889}
]
}
{
”id”: 12,
”nombres”: “René”,
”apellidos”: “Guamán”,
”dispositivos”: [
{“dispositivo”: http://.../usuarios/12/dispositivo/1033},
{“dispositivo”: http://.../usuarios/12/dispositivo/1038},
]
}

38. 38
Códigos de estado

Indican el resultado de la operación

Hay que tener cuidados con:

401 “Unauthorized”

segnifica realmente
“Unauthenticated”

403 “Forbidden”

segnifica realmente “Unauthorized”

Se requiere dar más información de un
error:

Errores internos (completan al código
de error de HTTP)

Descripción
Algunos código
200 – Petición correcta
201 – Petición completada y recurso creado correctamente
202 – Petición aceptada pero no completada
304 – No modificado
400 – Solicitud incorrecta
401 – No autorizado
403 - Prohibido
404 – No encontrado
405 – Método no permitido
406 – No aceptable. El servidor no puede devolver la
información en el formato solicitado en la petición
500 – Error interno del servidor
501 – No implementado

39. 39
MediaTypes

En la arquitectura REST no existe un formato de intercambio de información
predefinido

Se indica en las cabeceras / header

Header Accept en la petición

Header Content-Types en la respuesta

Ejemplo: application/json

Valores múltiples: Accept: application/json, text/plain

40. 40
Tipos MIME habituales
Esto permite que el servicio sea utilizado por diferentes clientes que están escritos en
diferentes lenguajes y que se ejecutan en diferentes plataformas y dispositivos. La
utilización de los tipos MIME y de la cabecera HTTP Accept es un mecanismo que se
conoce como negociación de contenido, que deja que los clientes elijan cuál es el
formato de datos que es adecuado para ellos y minimiza el acoplamiento de datos
entre el servicio y las aplicaciones que lo utilizan

41. 41
Ejemplos de petición

42. 42
¿Por qué usar REST?

Es sencillo de entender e implementar

Escalabilidad, independencia, seguridad, encapsulación, etc

43. 43
Cŕeditos
•Transparencias basadas por:
Servicios Web: RESTful https://blog.bi-geek.com/servicios-web-restful/

44. Networking académico:
Correo electrónico: [email protected]
Twitter: @rene5254
SlideShare: https://es.slideshare.net/rene5254
44
Gracias