UNIVERSIDAD DEL NORTE

DIVISIN DE ESPECIALIZACIONES
MAESTRIA EN GOBIERNO DE TIC


CONCEPTOS MODERNOS
PROF. MARGARITA CORONELL

Ensayo
SERVICIOS WEB SOAP Vs REST


Ing. Eliseo Castro Jimenez


9 de Octubre de 2014



2

INTRODUCCIN
Estamos en una era donde las organizaciones necesitan compartir informacin entre
sus sistemas, en poder lograr esa interaccin bajo un mismo lenguaje sin importar la
tecnologa que cuente las organizaciones y en que est se encuentre desarrollada estos
sistemas de informacin; por lo tanto, la evolucin de las tecnologas ha permitido
cumplir esta necesidad apoyado por la evolucin de las comunicaciones, como es el
caso del internet y su capacidad de poder transmitir datos de diferentes tipos y
tamaos.
Para dar conocimiento sobre como suplir esta necesidad, en cumplir con cabalidad
sobre unos de los objetivos de la Arquitectura Empresarial como es la Integracin,
hablaremos sobre dos diferentes tipos de interface ms utilizado entre diferentes
sistemas de informacin apoyado sobre la arquitectura de los Servicios Web, como lo
es SOAP (Simple Object Access Protocol) y REST (REpresentational State Transfer).

DESARROLLO
Para dar inicio al desarrollo de este documento, comenzaremos primero en dar un
concepto sobre que es un Servicio Web. De acuerdo a la definicin de la W3C, se
define como sistemas software diseados para soportar una interaccin interoperable
maquina a mquina sobre una red. Los Servicios Web suelen ser APIs Web que pueden
ser accedidas dentro de una red (principalmente Internet) y son ejecutados en el
sistema que los aloja. [1]
Los Servicios Web utilizan los protocolos HTTP, TCP, RPC, MSQ, entre otros, para poder
conectarse entre ellos y as enviar la informacin bajo un formato estndar como lo es
Formatted: Justified, Line spacing: 1.5 lines
3

XML (eXtensible Markup Language); este formato de dato es utilizado para el
transporte de informacin de los Servicios Web de tipo SOAP.
REST (REpresentational State Transfer)
REST es un tipo de arquitectura para los tipos de sistemas que trabaja bajo el protocolo
web, cuyo creador fue Roy Fielding, presentado en su tesis doctoral en el ao 2000.
REST se refiere a unas colecciones de recursos que son definidos y diseccionados,
logrando describir en cualquier interfaz que transmita datos bajo el dominio del HTTP,
sin contar con ninguna capa adicional, simplificando su comunicacin. Cabe aclarar
que REST no es un estndar, sino un estilo de arquitectura que se basa en: HTTP, URL,
representaciones de los recursos (XML, HTML, GIF, JPG, etc.), tipos MIME (text/xml,
text/html, entre otros).
REST debe cumplir con estos 6 principios [2]:
CLIENTE-SERVIDOR: Deben estar separado el Cliente con el Servidor a travs de
una interfaz uniforme, por lo tanto el Cliente no sabe cmo se obtiene la
informacin y el Servidor no sabe como se muestra en la interface de usuario.
NO MANEJA ESTADO: El Cliente debe contar con toda la informacin requerida
para procesar su solicitud sin necesidad de contar con un estado al lado del
Servidor, permitiendo la escalabilidad en las aplicaciones al no preocuparse por
el estado de conexin o de sesin al lado del Servidor.
CAPACES EN ALMACENAR EN CACHE: En la WWW los Clientes no tienen
mecanismos para almacenar las respuestas en el cache, por lo tanto deben ser
explicitas especificando si se permite manejar en cache o no.
SISTEMAS EN CAPAS: El Cliente no debe tener el conocimiento si est
consumiendo el servicio en un servidor final o por parte de un intermediario.
4

CDIGO BAJO DEMANDA: A nivel de Servidor, debe ser capaz de extender la
funcionalidad al Cliente, permitiendo transferir lgica que puedan utilizar,
ejemplo los JavaScript.
INTERFACE UNIFORME: Son recursos individuales que deben estar incluido ante
cualquier solicitud.
SOAP (Simple Object Access Protocol)
SOAP es un tipo de arquitectura para intercambio de mensajes en HTTP generalmente,
utilizando XML como formato de datos de transmisin de la informacin. SOAP puede
transferirse en varios protocolos de informacin como lo es SMTO, MIME, HTTP y TCP,
permitiendo ser ms lento y largo para transferir porque usa un protocolo adicional.
Adicional a esto, SOAP permite realizar ciertas acciones que REST no permite como los
es: manejo de transacciones, implementacin de una capa de seguridad, gestin de
excepciones en los mensajes, envi de datos complejos, es fuertemente acoplado, lo
que permite poder ser testado y depurado antes de poner en marcha la aplicacin.
SOAP Vs REST
A continuacin mostraremos de forma resumida las caractersticas, ventajas y
desventajas de cada una de estas tecnologas de servicios web.





5

CARACTERSTICAS DE SOAP & REST [1]


ALGUNAS VENTAJAS DE SOAP & REST [1]


R
E
S
T

Definicin de la operacin
en los mensajes.
Direccin nica para cada
instancia del proceso.
Cada operacin soporta
operaciones estandar.
Componentes dbilmente
acoplados.
S
O
A
P

Operaciones definidas con
puertos WSDL.
Direccin unica para todas
las operaciones.
Multiples instancia del
proceso comparten la
misma operacin.
Componentes fuertemente
acoplados.
REST
SOAP
Facil de utilizar
(Generalmente).
Posibe depuracin.
Operacin complejas puede
ser escondida en una
fachada.
Incrimenta la privacidad
Bajo consumo de recursos.
Instancia de proceso creada
explicitamente.
Cliente no necesita
informacin de
enrutamiento de la URI.
Facil de construir y adaptar.
6

POSIBLES DESVENTAJAS DE SOAP & REST [1]



CONCLUSIONES
La utilizacin de estos tipos de interfaz bajo servicios web para integrar los sistemas de
informacin, depender mucho de su propsito, requerimientos, arquitectura de su
infraestructura y en el sistema de informacin, y la plataforma de desarrollo, entre otros.
Aunque los desarrolladores prefieren ms el estilo REST por su alto uso en aplicaciones
web y el lenguaje de desarrollo al lado del cliente como lo es JQuery, cualquiera de las
dos opciones son vlida para su automatismo de integracin, pero cabe resaltar que
para el caso en particular del consumo de informacin de una aplicacin cliente Mobile
hacia el servidor, se recomienda usar REST por su bajo consumo de recurso en el canal
REST
Gran nmero de objetos.
manejar espacio de nombres (URIs),
puede ser engorroso.
Descripcin sintctica/semntica muy
informal.
Pocas herramientas de desarrollo.
SOAP
Clientes deben saber las operaciones y
semnticas de uso.
Se necesita puertos dedicados para
diferentes tipos de notificaciones.
Instancias de procesos creadas
implicitamente.
7

de comunicacin de dato y para desarrollos giles por su simplicidad de
implementacin.

BIBLIOGRAFIA

[1] R. N. Marset, Julio 2006. [En lnea]. Available:
http://users.dsic.upv.es/~rnavarro/NewWeb/docs/RestVsWebServices.pdf.
[2] C. A. M. Flores, Diciembre 2012. [En lnea]. Available: http://carlosmayta.blogspot.com/.
[3] C. Simoes, INUSUAL, Enero 2014. [En lnea]. Available: http://inusual.com/articulos/rest-vs-
soap-al-servicio-de-la-web/.
[4] SMARTBEAR, SOAPUI, [En lnea]. Available: http://www.soapui.org/The-World-Of-API-
Testing/soap-vs-rest-challenges.html.