3.6 Comparación REST/SOAP

Documentos relacionados
Tema 3.2.1: El Estilo Arquitectónico REST

Tema 3.1: Introducción a Servicios Web

Tema 3.6: El Estilo Arquitectónico REST

API: REST o RESTful WEB-SERVICES

Tema 5. APIs y Servicios web

Servicios Web. Desarrollo de Aplicaciones Empresariales

2.1 Introducción al Lenguaje XML

Introducción a los Servicios Web

Jorge De Nova Segundo

Listado del registro de mensajes de la plataforma SMS de LleidaNetworks vía HTTP

3.3 Casos de estudio

APLICACIONES DE INTERNET: SOAP

SERVICIOS WEB DE MODIFICACIÓN DE LA D.G. DEL CATASTRO Introducción general

Especificación de Uso. Servicios Web Externos API Servicio Licencias Ed. Superior V-0.1

5.1 Introducción a Servicios Web

Introducción a Web Services

Desarrollo y servicios web

Internet está evolucionando

Web Map Service (WMS)

Universidad Carlos III de Madrid

Características generales de un servicio web

Evolución de la Web y Servicios Web. Daniel Bruzual Marilyn Nowacka

JavaScript: Introducción

RMI. Aplicaciones Distribuidas

Desarrollo de WebServices- GEL XML

Modelo de aplicaciones Web clásico (1)

Tema VI. Servicios Web I. Introducción

Online Arquitecture. Page1. Video filmado con GeneXus tm 15

DOMÓTICA: PROTOCOLO UPNP Y HOGAR DIGITAL V. HERRAMIENTAS INTEL PARA EL USO Y DESARROLLO DE LA TECNOLOGÍA UPNP

Pasarela para envíos de faxes a través de interfaz HTTPS

Características generales de un servicio Web.

MWEB 2007 Acceso Dinámico a Servicios de una Infraestructura Web desde Teléfonos Móviles

Capítulo 7: Introducción a la dinámica de servicios Web

Características generales de un servicio Web. Jesús Torres Cejudo

Arquitectura e Integración de Sistemas Software. Proyecto: Gestión de Almacenes de Libros

Sistemas Operativos Distribuidos

Sesión 17. Servicios web RESTful

RESTful en Drupal 8. Creando Servicios Web desde el Core

Escuela Superior de Ingeniería

Sistemas Informáticos Industriales

Distribución de datos LiDAR en la IDERM

Sistemas Distribuidos Servicios web. Rodrigo Santamaría

Tema 4: Introducción a XML

Guía de uso para envío de SMS

Contacts REST: Guía de consumo Web Service

Tema 4: Diseño e Implementación de la Capa Web

Programming with C# DESCRIPCION MODULOS DE CAPACITACION. Sistemas Informáticos del Valle Módulo 1: Revisión de la sintaxis de C#

@ries: Interfaz servicios web Registro Telemático

UD 4: Instalación y administración de servicios Web SRI

Servicios Web. Andrés Pastorini. TRIA Tecnólogo Informático

Cursos de Extensión Universitaria UNIVERSIDAD DE OVIEDO. Servicios Web (II)

MASTER PROFESIONAL C# 5 Y ASP.NET MVC 5

Un nuevo middleware! Acceso directo, no mediante la simulación de un cliente

Sistemas Distribuidos Servicios web. Rodrigo Santamaría

Tema 4: Tecnologías Web Java

Consejería de Hacienda y Administración Pública. Alta de aplicaciones en la plataforma. Versión: v01r01 Fecha: 01/06/2011

De esta manera, cuando el usuario rellena un campo cómo el siguiente... <input type="text" name="telefono"> </form>

Desarrollo y servicios web

Unidad 2. Elementos Intermedios del Lenguaje

Acceso a datos desde PHP (avanzado) Múltiples submits a PHP, control, gestión de errores, visualización, jquery, datatables, AJAX

INGENIERÍA DEL SOFTWARE

Sistema Integral Multicanal de Atención al Ciudadano

MRW / WOOCOMMERCE. Plugin para la gestión de envíos y generación de etiquetas

SERVICIO DE ENVÍO MASIVO DE MENSAJES MMS MULTIMEDIA HTTPS/API

Demo. Todo el proceso de investigación en tres sencillos pasos

Punto 2 Características del Servicio Web. Juan Luis Cano

Servicios Web para el control de publicación de anuncios de notificación en el Tablón Edictal Único

TEMA 5. Otras arquitecturas distribuidas IV. Web Services

Ie118RcV1 Recogida del certificado de recepción de un documento expedido.

Sistemas Distribuidos Orientados a Objetos

TELKIA. Especificación, SMSBROKER HTTP Protocol TELKIA. Versión: 2.5 Fecha: Page 1

Service Oriented Architecture

Si usted quiere desarrollar con Bluevia y Java, esto es lo primero que debe saber

A continuación se comentan más profundamente estas implementaciones.

Bootstrapping Databases en equipos móviles

Ingeniería de Sistemas

PROTOCOLOS PARA LA INTERCONEXIÓN DE REDES

Definición de Catálogo. Teoría CSW (Catalogue Service Web) Servicios OGC para una IDE con SL. Metadatos: Hidrografía. Alejandra Sánchez Maganto IGN

Web Services Tecnologías asociadas

Guía de integración Pagomedios API Revisión Agosto 2017

Desarrollo Web con PHP y MySQL

Realización CU62: Registrar cuadrilla

Especificación de API SMS ITD Chile

SISTEMAS DISTRIBUIDOS MÓDULO 9

Servicios Web. Alberto Molina Coballes. Rodríguez. 16 de abril de 2012

. Recibir devoluciones de llamada HTTP para la notificación de entrega (recibos) cuando se recibe SMS-MT (o no) en la estación móvil.

TEMA 1. Introducción a las arquitecturas distribuidas

Tema 6: Comparativa CORBA/Servicios Web

PROYECTOS DE WEBSERVICE PARA DESARROLLADORES. 12 Agosto 2016

Web Service: Consulta de Arribo de Ómnibus Manual de referencia

Máster en Computación

Departamento de Informática Tributaria Subdirección General de Aplicaciones de Aduanas e II.EE. C/ Santa María Magdalena 16, Madrid

Antecedentes de Integración

Responda a las siguientes preguntas cortas justificando

Transcripción:

3.6 Comparación REST/SOAP

Comparativa (1) A diferencia del enfoque REST purista, el enfoque SOAP Al igual que cualquier otro enfoque RPC (e.g. CORBA), está pensado para concebir un servicio en términos de operaciones ad-hoc Define un formato XML para enviar las peticiones/respuestas En el caso de usar HTTP (lo normal), muchas librerías de programación invocan todas las operaciones con POST, dado que WSDL no especifica la semántica de las operaciones Ejemplo Movies SOAP El servicio ofrece un interfaz SOAP con cuatro operaciones ad-hoc: findmoviesbyreleasedate, addmovie, updatemovie y removemovie En una implementación REST purista de Movies El servicio sólo soportaría las operaciones estándares en HTTP (fundamentalmente GET, POST, PUT y DELETE) El servicio ofrecería 2 tipos de recursos Películas, por ejemplo con URL http://xxx/movies/purerest/movies Película, por ejemplo con URL de tipo http://xxx/movies/purerest/movie/<id>

Comparativa (2) En una implementación REST purista de Movies (cont) Dado que cada recurso tiene que disponer de una URL propia, los recursos de tipo Película se identifican por ejemplo con URLs de tipo http://xxx/movies/purerest/movie/<id> <id> no puede ser generado por el servicio, dado que para añadir una película se necesita su URL, y en consecuencia, un valor para <id> <id> tiene que ser único para todos los recursos de tipo Película <id> podría ser, por ejemplo, un identificador basado en el título original de la película Ejemplo: The_Curse_Of_The_Jade_Scorpion Si hubiese más de una película con el mismo título original, se podría añadir algo (e.g. número, fecha, etc.) después de <id> para diferenciar

Comparativa (3) REST purista: consulta de las películas que se estrenan en una fecha GET http://xxx/movies/pure-rest/ Movies?day=19&month=10&year=2001 A diferencia del enfoque REST no purista, devolvería un XML del tipo <?xml version="1.0" encoding="utf-8"?> <movies xmlns="http://ws.udc.es/movies/xml" xmlns:xlink="http://www.w3.org/1999/xlink"> <movie xlink:href="http://xxx/movies/pure-rest/movie/ The_Curse_Of_The_Jade_Scorpion"> <title>la Maldición del Escorpión de Jade</title> </movie> <movie xlink:href="http://xxx/movies/pure-rest/movie/ Amelie"> <title>amelie</title> </movie> </movies>

Comparativa (4) REST purista: consulta de las películas que se estrenan en una fecha (cont) Por cada película (recurso) se devuelve información básica (en este caso, el título) y su URL Si la aplicación cliente muestra la información interactivamente Mostrará la información básica de cada película Cada vez que el usuario selecciona una película, la aplicación invoca (GET) la URL asociada a esa película para obtener su información detallada (representación del recurso) y la muestra Si la aplicación cliente necesita acceder a toda la información de todas las películas, tiene que realizar una petición (GET) por cada película devuelta

Comparativa (5) REST purista: consulta de la información de una película GET http://xxx/movies/pure-rest/movie/amelie Devolvería la siguiente representación del recurso <?xml version="1.0" encoding="utf-8"?> <movie> <title>la Maldición del Escorpión de Jade</title> <runtime>103</runtime> <time:date day="19" month="10" year="2001"/> <director>jean-pierre Jeunet</director>... </movie> La representación de una película no utiliza el tag <identifier> En el enfoque REST purista, el identificador de un recurso es su URL

Comparativa (6) REST purista: añadir la información de una película PUT http://xxx/movies/pure-rest/movie/amelie Al igual que en el enfoque REST no purista, se envía el XML con la información de la nueva película en el cuerpo del mensaje A diferencia del enfoque REST no purista, no se devuelve ningún XML REST purista: actualizar la información de una película POST http://xxx/movies/pure-rest/movie/amelie Al igual que en el enfoque REST no purista, se envía el XML con la información de la nueva película (sin tag identifier) en el cuerpo del mensaje A diferencia del enfoque REST no purista, no se devuelve ningún XML

Comparativa (7) REST purista: eliminar la información de una película DELETE http://xxx/movies/pure-rest/movie/amelie A diferencia del enfoque REST no purista, no se pasa el parámetro HTTP identifier ni se devuelve ningún XML Todas las respuestas utilizan apropiadamente los código de estado (retorno) HTTP para indicar el resultado de la operación invocada Como se comentó en el apartado 3.2.1, el hecho de pensar en recursos y en operaciones HTTP con semántica estándar (GET, PUT, POST, DELETE, etc.), permite colocar intermediarios (e.g. caché) entre el cliente y el servicio, que aunque no entiendan los datos intercambiados (es decir, las representaciones de los recursos), comprenden la semántica asociada a las operaciones (leer, añadir, actualizar, borrar, etc.)

Comparativa (y 8) Al igual que SOAP, en el enfoque REST no purista, a la hora de diseñar el servicio, no se piensa en recursos a los que aplicar operaciones HTTP estándar, sino en operaciones ad-hoc En Movies REST no purista, se disponía de una URL para cada operación ofrecida por el servicio (http://.../findmoviesbyreleasedate, http://.../addmovie, etc.), invocables por GET o POST, dependiendo de la operación A diferencia de SOAP, en el enfoque REST no purista, al menos se utilizan las operaciones estándar GET y POST para distinguir entre operaciones de lectura y modificación No permite todas las ventajas potenciales del enfoque REST purista Al igual que el enfoque REST purista, el servicio es más fácilmente accesible desde lenguajes en los que no hay un soporte tan directo para SOAP