3.6 Comparación REST/SOAP

Transcripción

1 3.6 Comparación REST/SOAP

2 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 Película, por ejemplo con URL de tipo

3 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 <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

4 Comparativa (3) REST purista: consulta de las películas que se estrenan en una fecha GET 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=" xmlns:xlink=" <movie xlink:href=" The_Curse_Of_The_Jade_Scorpion"> <title>la Maldición del Escorpión de Jade</title> </movie> <movie xlink:href=" Amelie"> <title>amelie</title> </movie> </movies>

5 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

6 Comparativa (5) REST purista: consulta de la información de una película GET 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

7 Comparativa (6) REST purista: añadir la información de una película PUT 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 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

8 Comparativa (7) REST purista: eliminar la información de una película DELETE 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.)

9 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 ( 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