UNIVERSIDAD MAYOR DE SAN SIMÓN

FACULTAD DE CIENCIAS Y TÉCNOLOGIA

INGENIERIA DE SISTEMAS

COMPARACIÓN DE LAS CARACTERÍSTICAS DE UN

API REST Y SOAP

ELABORADO POR: ARIEL CESPEDES GALVEZ

TUTOR: ING. EDSON ARIEL TERCEROS TORRICO

CARRERA: ING. DE SISTEMAS

FECHA: OCTUBRE 2018

COCHABAMBA – BOLIVIA
 ii

Dedico esta Monografía principalmente a Dios, por haberme dado la

vida y permitirme llegar hasta este momento tan importante de mi

formación profesional.

De igual forma, a mis padres Flaviana y Gregorio por haber sido el

pilar fundamental de mi formación personal, que han sabido

formarme con buenos sentimientos, hábitos y valores, lo cual me

ayudo salir adelante en los momentos difíciles.

A mis hermanos (as) por estar ahí siempre apoyándome en cada paso.

A mis compañeros, docentes y a mi casa de estudios UMSS.

 CONTENIDO
INDICE DE FIGURAS 5

INDICE DE TABLAS 6

Resumen 7

Introducción 8

1. Generalidades 10

1.1 Antecedentes Generales 10

1.2 Antecedentes Específicos 11

2. Metodología 11

3. API REST 12

3.1 Características correspondientes al estándar API REST. 12

3.1.1 Ventajas de las API REST 14

3.1.2 Experiencia de Usuario 17

3.1.3 REST requiere menos recursos del servidor 17

3.2 Desarrollo basado en API REST, la mejor manera de proyectar un backend. 18

3.2.1 Desarrollo Backend tradicional 18

3.2.2 Desarrollo basado en API REST 19

3.2.3 Desarrollar fácilmente un API REST 19

3
 4

3.2.4 NoSQL 20

4. REST 21

4.1 Motivación de REST 22

4.2 Principios de REST 23

4.2.1 Escalabilidad de la interacción con los componentes. 23

4.2.2 Generalidad de interfaces. 23

4.2.3 Puesta en funcionamiento independiente. 23

4.2.4 Compatibilidad con componentes intermedios. 23

4.3 Restricciones de REST 24

4.3.1 Identificación de recursos. 24

4.3.2 Manipulación de Recursos. 24

4.3.3 Mensajes auto-descriptivos. 24

4.3.4 Hipermedia. 25

5. SOAP 26

5.1 Definición SOAP 26

5.3 Características de los API REST y SOAP 30

5.4 Diferencias entre API REST y SOAP 32

6. Conclusiones 37

7. Bibliografía 39
 5

INDICE DE FIGURAS

Ilustración 1: Separación entre el cliente y el servidor ........................................................... 15

Ilustración 2: REST Services ..................................................................................................... 26

Ilustración 3: SOAP Services ..................................................................................................... 26

 6

INDICE DE TABLAS

Tabla 1: Características de los API REST y SOAP ................................................................. 32

Tabla 2: Diferencias entre API REST y SOAP ........................................................................ 37

 7

RESUMEN

En el desarrollo web de las aplicaciones empresariales existe una variedad de tecnologías y las

más sobresalientes son las tecnologías API REST y SOAP.

Se realizó una monografía entre los servicios web API REST y SOAP, este trabajo fue basado en

la comparación de las características de ambas tecnologías web.

SOAP, Los servicios SOAP o mejor conocimos simplemente como Web Services, “protocolo

estándar que define cómo dos objetos en diferentes procesos pueden comunicarse por medio de

intercambio de datos XML”. Por lo tanto, queda claro que la comunicación se realiza mediante

XML, lo cual nos debe de quedar muy claro, pues es en este aspecto donde radican las principales

diferencias contra REST.

API REST, El lanzamiento del nuevo sistema REST como protocolo de intercambio y

manipulación de datos en los servicios de internet cambió por completo el desarrollo de software

a partir de 2000. Ya casi toda empresa o aplicación dispone de una API REST para la creación de

negocio.

Ambos sistemas web fueron el punto de partida para dicha monografía realizada.

El propósito de esta monografía es ver la comparación de ambos servicios web y las características

de las mismas y así mismo las diferencias.

 8

INTRODUCCIÓN

Con la llegada de este nuevo milenio, el estándar dictaminado por REST (Representational State

Transfer-Transferencia de Estado Representacional) cambio por completo la manera de

desarrollar aplicaciones consumiendo datos remotos. Este nuevo enfoque de desarrollo de

proyectos y servicios web propulso el estándar REST, el modelo de servicios más utilizado para

generar APIs para el consumo de datos remotos o locales, sin tener que depender del acceso directo

hacia una base de datos SQL o NoSQL.

Hoy podemos encontrar que todas las grandes empresas (Twitter, Facebook, YouTuBe, LinkedIN,

Google+, entre otras tantas) promueven el acceso y el uso de sus datos mediante el modelo API

REST. Este protocolo estándar gano el terreno de la compartición de datos, quitándole la

exclusividad a SOAP, un servicio por excelencia cuyo uso, en la actualidad, quedo olvidado a

empresas bancarias, compañías de servicios y otros sectores donde la reingeniería de productos se

realiza en periodos extensos. (Luna, Claudio, & Lacano , p. 11)

REST cambio por completo la ingeniería de software a partir del 2000. Este nuevo enfoque de

desarrollo de proyectos y servicios web fue definido por Roy Fielding, el padre de la especificación

HTTP y uno de los referentes internacionales en todo lo relacionado con la arquitectura de redes,

en su disertación “Architectural Styles and the Design of Network-Based Software Architectures”.

En la actualidad en el campo de las APIs REST es, el alfa y omega del desarrollo de servicios de

aplicaciones.

REST es cualquier interfaz entre sistemas que use HTTP para obtener datos o generar operaciones

sobre esos datos en todos los formatos posibles, como XML y JSON. Es una alternativa en auge a
 9

otros protocolos estándar de intercambio de datos como SOAP (Simple Object Access Protocol),

que disponen de una gran capacidad, pero también mucha complejidad.

A veces es preferible una solución más sencilla una manipulación de datos como REST. Según

(BBVA l API_Market, 2016)

SOAP es un protocolo basado en XML de la World Wide Web que describe mensajes. Los objetos

de SOAP son la independencia del hardware, sistema operativo y protocolos de comunicaciones.

SOAP está basada en un protocolo anterior llamado XML-RPC, que era un modo de hacer una

llamada a procedimiento remoto a través de HTTP con un archivo en XML. Posteriormente se

amplió. La diferencia más importante fue que los parámetros de la llamada tienen nombre y su

orden es diferente y son las ampliaciones de este tipo las que dan flexibilidad. Según (Manuel, p.

61)
 10

1. GENERALIDADES

1.1 Antecedentes Generales

La Wold Wide Web Consortium, define un servicio web como Un sistema de software diseñado

para soportar interacción interoperable maquina a máquina sobre una red. De un modo más

practico los podemos entender como un tipo de funcionalidad para los usuarios, disponible en

internet, que no está asociado a ningún tipo de sistema operativo o lenguaje de programación y

que utiliza mensajes formateados en XML para las comunicaciones entre maquinas. Es común

también que los servicios web tengan una interfaz pública que describa sus métodos y permita su

integración sencilla en un sistema.

El OMG (Object Management Group) es un consorcio de más de 800 empresas, entre las que se

encuentran IBM, HP, etc. La finalidad del OMG es desarrollar y estandarizar un conjunto de

tecnologías como el UML (Unified Modelling Language), MDA (Model Driven Architecture), que

es la evolución de UML, o CORBA (Common Object Request Broker Architecture) entre otros.

CORBA, es una arquitectura que permite que varios componentes, quizás escritos en distintos

lenguajes de programación y funcionando en distintas maquinas, puedan cooperar entre ellos.

Un objeto CORBA es una entidad virtual que puede ser localizada por un ORB y ser llamada por

clientes. Los objetos CORBA ofrecen servicios a otros componentes a través de su interface. El

IDL (Interfaz Definition Language) es la forma que tiene CORBA de describir dichos interfaces,

y lo hace estableciendo un contrato entre el cliente y el servidor que describe los tipos y los

interfaces de los objetos que serán usados entre ambos. Según (CALLEJAS, 2013, pp. 35p, 39p)

El objetivo de CORBA siempre ha sido permitir la interconexión abierta de una amplia variedad

de lenguajes, implementaciones y plataformas. Por tanto, OMG nunca se basó en estándares

 11

binarios (a nivel de ejecutables), sino en estándares que permitiesen implementaciones de

diferentes proveedores de productos compatibles con CORBA.

La desventaja de este enfoque tan abierto es que cada uno de los productos compatibles con

CORBA no puede operar de forma eficiente a nivel binario, sino que deben utilizar protocolos de

más alto nivel.

1.2 Antecedentes Específicos

Los servicios Web como REST y SOAP son tecnologías o los mecanismos para poder comunicar

un sistema con cualquier otro sistema en otro lenguaje.

El medio que define el intercambio de datos entre objetos a través de XML es SOAP, que proviene

de XML RCP.

REST, Transferencia de Estado Representacional (Representational State Transfer) utiliza XML

y HTTP directamente, sin mover ningún servicio de abstracción para protocolos de intercambio

de mensajes.

Puede hacer también uso de JSON como contenedor de información, generalmente cuando se

dispone de pocos recursos, debido a su gran rendimiento y bajo consumo. Según, (JOSE VILLAR

CUELI, FEDERICOHUERCANO RUIZ)

2. METODOLOGÍA

Para el presente trabajo se utilizarán los siguientes métodos de investigación:

 Método Bibliográfico, debido a que se realizara la lectura y compilación de libros

relacionados al tema de estudio.

 Método Analítico, debido a que se procederá a revisar y analizar ordenadamente

documentos relacionados al tema de estudio, para la redacción del presente trabajo.

 12

3. API REST

Hoy en día estamos ante una corriente que se está extendiendo mucho en el ámbito de la tecnología

actual, REST, que soporta un nuevo modelo de desarrollo de software diferente, capaz de aportar

varias ventajas en el ciclo de vida de las aplicaciones.

En la actualidad no existe proyecto o aplicación que no disponga de una API REST para la creación

de servicios profesionales a partir de ese software. Twitter, YouTube, los sistemas de

identificación con Facebook, hay cientos de empresas que generan negocio gracias a REST y las

APIs REST. Sin ellas, todo el crecimiento en horizontal sería prácticamente imposible. Esto es así

porque REST es el estándar más lógico, eficiente y habitual en la creación de APIs para servicios

de Internet.

Buscando una definición sencilla, REST es cualquier interfaz entre sistemas que use HTTP para

obtener datos o generar operaciones sobre esos datos en todos los formatos posibles, como XML

y JSON. Es una alternativa en auge a otros protocolos estándar de intercambio de datos como

SOAP (Simple Object Access Protocol), que disponen de una gran capacidad, pero también mucha

complejidad. A veces es preferible una solución más sencilla de manipulación de datos como

REST.

3.1 Características correspondientes al estándar API REST.

 Protocolo cliente/servidor sin estado.

Cada petición HTTP contiene toda la información necesaria para ejecutarla, lo que permite

que ni cliente ni servidor necesiten recordar ningún estado previo para satisfacerla.

Aunque esto es así, algunas aplicaciones HTTP incorporan memoria caché. Se configura

lo que se conoce como protocolo cliente-caché-servidor sin estado: existe la posibilidad

 13

de definir algunas respuestas a peticiones HTTP concretas como en memoria, con el

objetivo de que el cliente pueda ejecutar en un futuro la misma respuesta para peticiones

idénticas. De todas formas, que exista la posibilidad no significa que sea lo más

recomendable.

 Las operaciones más importantes relacionadas con los datos en cualquier sistema REST y

la especificación HTTP son cuatro:

POST (crear): Se utiliza para enviar una entidad a un recurso en específico, causando a

menudo un cambio en el estado o efectos secundarios en el servidor.

GET (leer y consultar): Solicita una representación de un recurso específico. Las

peticiones que usan el método GET solo deben recuperar datos.

PUT (editar): Reemplaza todas las representaciones actuales del recurso de destino con la

carga útil de la petición.

DELETE (eliminar): Elimina un recurso en específico.

 Operatoria de objetos mediante URL.

Los objetos en REST siempre se manipulan a partir de la URI. Es la URI y ningún otro

elemento el identificador único de cada recurso de ese sistema REST.

La URI nos facilita acceder a la información para su modificación o borrado, o, por

ejemplo, para compartir su ubicación exacta con terceros.

 Interfaz uniforme.

Para la transferencia de datos en un sistema REST, este aplica acciones concretas (POST,

GET, PUT y DELETE) sobre los recursos, siempre y cuando estén identificados con una
 14

URI. Esto facilita la existencia de una interfaz uniforme que sistematiza el proceso con la

información.

 Sistema de capas.

Arquitectura jerárquica entre los componentes. Cada una de estas capas lleva a cabo una

funcionalidad dentro del sistema REST.

 Uso de hipermedias.

Ese término que data del año 1965, es una extensión del concepto de hipertexto, que

desemboco luego de algunos años en lo que hoy conocemos como desarrollo de páginas

web, Hypermedia define la capacidad de una interfaz de desarrollo de aplicaciones,

proporcionando al cliente y usuario enlaces hipermediales adecuados para ejecutar

acciones determinadas sobre los datos de trabajar. En el caso de una API REST, el

concepto de hipermedia explica la capacidad de una interfaz de desarrollo de aplicaciones

de proporcionar al cliente y al usuario los enlaces adecuados para ejecutar acciones

concretas sobre los datos.

 Hateadas.

El principio de HATEOAS (Hypermedia A The Engine Of Application State) es el que lo

define como una verdadera API REST. El principio hace que cada vez que se solicita una

operación al servidor, este devuelve una respuesta.

3.1.1 Ventajas de las API REST

 Separación entre el cliente y el servidor.

El protocolo REST separa totalmente la interfaz de usuario del servidor y el

almacenamiento de datos. Eso tiene algunas ventajas cuando se hacen desarrollos.

 15

Por ejemplo, mejora la portabilidad de la interfaz a otro tipo de plataformas, aumenta la

escalabilidad de los proyectos y permite que los distintos componentes de los desarrollos

se puedan evolucionar de forma independiente.

En este sentido otra ventaja importantísima es la posibilidad de crear tantos frontales como

necesites con la misma API. Igual comienzas desarrollando una web, pero con la misma

API podrás desarrollar también una aplicación para iOS, Android y si mañana gustas para

Windows 8, Windows Phone, el próximo Windows 10, Blackberry, FirefoxOS y tantos

como vengan en el futuro a encajar con tu estrategia de negocio.

Ilustración 1: Separación entre el cliente y el servidor

Fuente: (Alvarez, Miguel Angel, 2014)

Si necesitas evolucionar/re factorizar uno de los dos, back o front, se puede hacer de manera

separada, siempre que se mantenga la interfaz del API.

 16

 Visibilidad, fiabilidad y escalabilidad.

La separación entre cliente y servidor tiene una ventaja evidente y es que cualquier equipo

de desarrollo puede escalar el producto sin excesivos problemas. Se puede migrar a otros

servidores o realizar todo tipo de cambios en la base de datos, siempre y cuando los datos

de cada una de las peticiones se envíen de forma correcta.

Esta separación facilita tener en servidores distintos el front y el back y eso convierte a las

aplicaciones en productos más flexibles a la hora de trabajar.

Al final solo te tienes que preocupar que el nexo cliente / servidor esté correcto. Puedes

hacer cambios en tu servidor, lenguajes, bases de datos, etc. y mientras devuelvas los datos

que toca todo irá correctamente.

A la hora de ejecutar tu aplicación también tienes una flexibilidad mucho mayor. Las

páginas del front las puedes enviar desde unos servidores y las API pueden estar alojadas

en servidores independientes, tantos como necesites. Por las características de REST

(principalmente no guardar estado) es indiferente qué servidor atienda cada solicitud, pues

es el propio cliente el que tiene que mandar el estado al servidor, así que el balanceo de

carga es mucho más simple que en aplicaciones tradicionales donde el front está mezclado

con el back. También tienes la aproximación de las "micro APIs", en las que puedes dividir

los procesos en diferentes servidores que atiendan a diferentes tipos de operaciones del

API. Según, (Alvarez, Miguel Angel, 2014)

 La API REST.

Siempre es independiente del tipo de plataformas o lenguajes: la API REST siempre se

adapta al tipo de sintaxis o plataformas con las que se estén trabajando, lo que ofrece una
 17

gran libertad a la hora de cambiar o probar nuevos entornos dentro del desarrollo. Con una

API REST se pueden tener servidores PHP, Java, Python o Node.js. Lo único que es

indispensable es que las respuestas a las peticiones se hagan siempre en el lenguaje de

intercambio de información usado, normalmente XML o JSON.

Según, (BBVA l API_MARKET, 2016)

3.1.2 Experiencia de Usuario

Aunque eso depende más de cómo está hecha la parte del cliente, teóricamente el desarrollo de

sitios web basados en un API puede dar mejor desempeño que uno tradicional. Cuando haces una

solicitud al servidor lo que tienes como respuesta son datos planos, que requieren tiempos de

transferencia menores que si esos mismos datos los recibieras mezclados con el HTML/CSS de la

presentación. En este tipo de aplicaciones web no necesitas recargar la página, aunque esto no es

una ventaja específica del desarrollo basado en REST, sino del uso de Ajax en general, con el que

podemos conseguir aplicaciones web que se asemejan más a aplicaciones de escritorio. Según,

(Alvarez, Miguel Angel, 2014)

3.1.3 REST requiere menos recursos del servidor

Esto no es necesariamente cierto, aunque en muchos casos sí se pueda deducir. Hay muchas

opiniones alrededor de REST. Nosotros basamos esa afirmación en estos motivos:

 No mantener el estado, no requiere memoria, se pueden atender más peticiones

 No requiere escribir el HTML, por lo tanto, tienes menos procesamiento en el servidor

Según, (desarrolloweb.com, 2014)

 18

3.2 Desarrollo basado en API REST, la mejor manera de proyectar un backend.

El desarrollo de aplicaciones no ha parado de avanzar y de presentar novedades prácticamente

desde que nació y lo hace a una velocidad de vértigo. Los desarrolladores están literalmente

saturados ante opciones nuevas, lenguajes, arquitecturas, librerías o frameworks. Y esto es un no

parar, ya que las alternativas crecen semana tras semana. Ante ese panorama de continuo avance,

nos encontramos con corrientes que, por sus ventajas y versatilidad, están adquiriendo cada vez un

mayor protagonismo, como es el caso del desarrollo basado en API REST, algo en lo que

profundizamos hoy.

3.2.1 Desarrollo Backend tradicional

El desarrollo del lado del servidor tradicional se basaba en construir sistemas que devolvieran al

cliente código HTML, capaz de ser interpretado directamente por el navegador. De esta manera,

cuando se programaba en PHP, Python, .NET, etc. lo normal era que se entregase al navegador

todo lo necesario para “pintar” la página a su usuario.

El punto débil de esta alternativa se basa principalmente en:

 Hoy no se consume el servicio web solo a través de Internet, sino también por medio de

aplicaciones para móviles, etc. Si producimos HTML desde el lado del backend, es muy

probable que tengamos que programar varias veces ese back-end para cada sistema al que

lo queramos portar.

 Ante la cantidad de alternativas que aparecen con tanta velocidad, la parte que menos

cambia es la del backend, por lo que es interesante que podamos desarrollar esa capa de

manera que se pueda adaptar a cualquier tipo de librería del lado del frontal.
 19

3.2.2 Desarrollo basado en API REST

En cambio, cuando desarrollamos un servicio backend construyendo un API, nos aseguramos que

se pueda consumir desde cualquier sistema o cliente. El API no devuelve más que datos, que están

desacoplados a cualquier modo de visualización. Si estamos implementando una web,

consumiremos el API desde cualquiera de los frameworks o librerías Javascript populares,

como AngularJS, Polymer o ReactJS. También se podrán consumir los servicios del API desde

aplicaciones desarrolladas en Java para Android o Swift/Objective C para iOS, por ejemplo.

Dentro de las alternativas de construcción de un API, REST es una que simplifica mucho el

funcionamiento, dado que se elimina todo lo relacionado al estado de la aplicación. Aunque REST

no almacena ninguna información de la sesión de los usuarios, esto es algo que se resuelve

mediante un token que el cliente debe enviar al servidor en cada solicitud que se realice.

3.2.3 Desarrollar fácilmente un API REST

En el ecosistema backend, la mayoría de los lenguajes nos permiten construir API REST de manera

fácil, mediante diversas librerías o frameworks.

 PHP.

Existen frameworks potentes como Symfony o Laravel capaces de acelerar mucho el

desarrollo de un API. Además, hay muchos microframeworks que tienen como principal

objetivo el desarrollo de API REST, desechando todo lo pesado y no tan útil de un

framework convencional, como Lumen o Slim.

 NodeJS.

El desarrollo con NodeJS de un API REST es especialmente indicado, dado que nos

permite construir el backend con el mismo lenguaje con el que se construye el front-end,
 20

evitando la fatiga de pasar de un lenguaje a otro cuando se desarrollan ambas capas de un

proyecto web. Además, dadas las características de esta plataforma, también se hace muy

adecuada para el desarrollo RESTful dado que Node, al no ser bloqueante, puede atender

a más usuarios de manera concurrente. En NodeJS, hay frameworks potentes para el

desarrollo de APIs y aplicaciones en general, como Express o algunos enfocados al

desarrollo de APIs de manera más particular como SailsJS.

 .NET.

En esta tecnología, también existen diversas alternativas sencillas y rápidas para

implementar un API. El propio Microsoft nos ofrece ASP.NET Web API, un complemento

esencial para construir servicios HTTP especialmente pensados para REST.

3.2.4 NoSQL

En el lado del backend y cuando hablamos de innovación, no podemos dejar de lado las bases de

datos. En concreto, hay un tipo de bases de datos que marcan la diferencia con respecto a las

opciones tradicionales. Son las bases de datos no relacionales, comúnmente conocidas como

NoSQL.

Este tipo de bases de datos combinan muy bien con los modelos de desarrollo basados en REST y

con movimientos emergentes como el IoT (Internet of Things), ya que nos permiten grandes

volúmenes de información a gran velocidad de procesamiento y concurrencia. Esto se aborda a

costa de sacrificar algunas de las ventajas de acceso a la información de las relacionales, por lo

que hay que saber que en el mundo del desarrollo no hay balas de plata y por tanto, no siempre

son la solución para todos los problemas. Según (Galan, 2016)

 21

4. REST

REST (Representational State Transfer) es un estilo de arquitectura de software para sistemas

hipermedias distribuidos tales como la Web. El término fue introducido en la tesis doctoral de Roy

Fielding en 2000, quien es uno de los principales autores de la especificación de HTTP.

En realidad, REST se refiere estrictamente a una colección de principios para el diseño de

arquitecturas en red. Estos principios resumen como los recursos son definidos y diseccionados.

El término frecuentemente es utilizado en el sentido de describir a cualquier interfaz que transmite

datos específicos de un domino sobre HTTP sin una capa adicional, como hace SOAP. Estos dos

significados pueden chocar o incluso solaparse. Es posible diseñar un sistema software de gran

tamaño de acuerdo con la arquitectura propuesta por Fielding sin utilizar HTTP o sin interactuar

con la Web. Así como también es posible diseñar una simple interfaz XML+HTTP que no sigue

los principios REST, y en cambio seguir un modelo RPC. Cabe destacar que REST no es un

estándar, ya que es tan solo un estilo de arquitectura. Aunque REST no es un estándar, está basado

en estándares:

 HTTP

 URL

 Representación de los recursos: XML/HTML/GIF/JPEG/…

 Tipos MIME: text/xml, text/html,etc.

 22

Ilustración 2: Rest Services

Fuente: ( (Blancarte, 2017)

4.1 Motivación de REST

La motivación de REST es la de capturar las características de la Web que la han hecho tan exitosa.

Si pensamos un poco en este éxito, nos daremos cuenta que la Web ha sido la única aplicación

distribuida que ha conseguido ser escalable al tamaño de Internet. El éxito lo debe al uso de

formatos de mensaje extensibles y estándares, pero además cabe destacar que posee un esquema

de direccionamiento global (estándar y extensible a su vez). En particular, el concepto central de

la Web es un espacio de URIs unificado. Las URIs permiten la densa red de enlaces que permiten

a la Web que sea tan utilizada. Por tanto, ellos consiguen tejer una mega-aplicación. Rafael

Navarro Marset. Modelado, Diseño e Implementación de Servicios Web 2006-07 REST vs Web

Services 5/19 Las URIs identifican recursos, los cuales son objetos conceptuales. La

representación de tales objetos se distribuye por medio de mensajes a través de la Web. Este

sistema es extremadamente desacoplado. Estas características son las que han motivado para ser

utilizadas como guía para la evolución de la Web.

 23

4.2 Principios de REST

El estilo de arquitectura subyacente a la Web es el modelo REST. Los objetivos de este estilo de

arquitectura se listan a continuación:

4.2.1 Escalabilidad de la interacción con los componentes.

La Web ha crecido exponencialmente sin degradar su rendimiento. Una prueba de ellos es la

variedad de clientes que pueden acceder a través de la Web: estaciones de trabajo, sistemas

industriales, dispositivos móviles, etc.

4.2.2 Generalidad de interfaces.

Gracias al protocolo HTTP, cualquier cliente puede interactuar con cualquier servidor HTTP sin

ninguna configuración especial. Esto no es del todo cierto para otras alternativas, como SOAP para

los Servicios Web.

4.2.3 Puesta en funcionamiento independiente.

Este hecho es una realidad que debe tratarse cuando se trabaja en Internet. Los clientes y servidores

pueden ser puestas en funcionamiento durante años. Por tanto, los servidores antiguos deben ser

capaces de entenderse con clientes actuales y viceversa. Diseñar un protocolo que permita este tipo

de características resulta muy complicado. HTTP permite la extensibilidad mediante el uso de las

cabeceras, a través de las URIs, a través de la habilidad para crear nuevos métodos y tipos de

contenido.

4.2.4 Compatibilidad con componentes intermedios.

Los más populares intermediaros son varios tipos de proxys para Web. Algunos de ellos, las

caches, se utilizan para mejorar el rendimiento. Otros permiten reforzar las políticas de seguridad:

firewalls. Y por último, otro tipo importante de intermediarios, gateway, permiten encapsular
 24

sistemas no propiamente Web. Por tanto, la compatibilidad con intermediarios nos permite reducir

la latencia de interacción, reforzar la seguridad y encapsular otros sistemas.

4.3 Restricciones de REST

REST logra satisfacer estos objetivos aplicando las siguientes cuatro restricciones:

4.3.1 Identificación de recursos.

Esto se consigue mediante el uso de URIs. HTTP es un protocolo centrado en URIs. Los recursos

son los objetos lógicos a los que se le envían mensajes.

4.3.2 Manipulación de Recursos.

Los recursos no pueden ser directamente accedidos o modificados. Más bien se trabaja con

representaciones de ellos. Cuando se utiliza un método PUT para enviar información, se coge

como una representación de lo que nos gustaría que Rafael Navarro Marset. Modelado, Diseño e

Implementación de Servicios Web 2006-07 REST vs Web Services 6/19 el estado del recurso fuera.

Internamente el estado del recurso puede ser cualquier cosa desde una base de datos relacional a

un fichero de texto.

4.3.3 Mensajes auto-descriptivos.

REST dicta que los mensajes HTTP deberían ser tan descriptivos como sea posible. Esto hace

posible que los intermediarios interpreten los mensajes y ejecuten servicios en nombre del usuario.

Uno de los modos que HTTP logra esto es por medio del uso de varios métodos estándares, muchos

encabezamientos y un mecanismo de direccionamiento. Por ejemplo, las cachés Web saben que

por defecto el comando GET es cacheable (ya que es side-effect-free) en cambio POST no lo es.

Además, saben cómo consultar las cabeceras para controlar la caducidad de la información. HTTP
 25

es un protocolo sin estado y cuando se utiliza adecuadamente, es posible interpretar cada mensaje

sin ningún conocimiento de los mensajes precedentes.

4.3.4 Hipermedia.

Es un mecanismo del estado de la aplicación. El estado actual de una aplicación Web debería ser

capturada en uno o más documentos de hipertexto, residiendo tanto en el cliente como en el

servidor. El servidor conoce sobre el estado de sus recursos, aunque no intenta seguirle la pista a

las sesiones individuales de los clientes.

Esta es la misión del navegador, él sabe cómo navegar de recurso a recurso, recogiendo

información que el necesita o cambiar el estado que el necesita cambiar.

En la actualidad existen millones de aplicaciones Web que implícitamente heredan estas

restricciones de HTTP. Hay una disciplina detrás del diseño de sitios Web escalables que puede

ser aprendida de los documentos de arquitectura Web o de varios estándares. Por otra parte,

también es verdad que muchos sitios Web comprometen uno más de estos principios, como por

ejemplo, seguir la pista de los usuarios moviéndose a través de un sitio. Esto es posible dentro de

la infraestructura de la Web, pero daña la escalabilidad, volviendo un medio sin conexión en todo

lo contrario.

Los defensores de REST han creído que estas ideas son tan aplicables a los problemas de

integración de aplicaciones como los problemas de integración de hipertexto. Fielding es bastante

claro diciendo que REST no es la cura para todo. Algunas de estas características de diseño no

serán apropiadas para otras aplicaciones. Sin embargo, aquellos que han decidido adoptar REST

como un modelo de servicio Web sienten que al menos articula una filosofía de diseño con

fortaleza, debilidades y áreas de aplicabilidad documentada.

 26

5. SOAP

Los servicios SOAP o mejor conocimos simplemente como Web Services, son servicios que basan

su comunicación bajo el protocolo SOAP (Simple Object Access Protocol) el cual este definido

como “protocolo estándar que define cómo dos objetos en diferentes procesos pueden comunicarse

por medio de intercambio de datos XML”. Por lo tanto, queda claro que la comunicación se realiza

mediante XML, lo cual nos debe de quedar muy claro, pues es en este aspecto donde radican las

principales diferencias contra REST.

Los servicios SOAP funcionan por lo general por el protocolo HTTP que es lo más común cuando

invocamos un Web Services, sin embargo, SOAP no está limitado a este protocolo, si no que puede

ser enviado por FTP, POP3, TCP, Colas de mensajería (JMS, MQ, etc). Pero como comentaba,

HTTP es el protocolo principal. Según, (Blancarte, 2017)

Ilustración 3: SOAP Services

Fuente: (Blancarte, 2017)

5.1 Definición SOAP

Protocolo de comunicación, basado en XML, que sirve para la invocación de los Servicios Web a

través de un protocolo de transporte, como HTTP (ó SMTP, etc.). Consta de tres partes: una
 27

descripción del contenido del mensaje, unas reglas para la codificación de los tipos de datos en

XML y una representación de las llamadas RPC para la invocación y respuestas generadas por el

Servicio Web. El mensaje SOAP está compuesto por un envelope (sobre), cuya estructura está

formada por los siguientes elementos: header (cabecera) y body (cuerpo). Según, (Flores, 2012)

Son las siglas Estándar Objecet Access Protol, o protocolo estándar de acceso a objetos.

Mediante SOAP se define el estándar que regula de serializacion o empaquetado de datos y

generación de los mensajes transmitidos durante una transacción en la que se incluye un web

service.

Aunque SOAP no es la única manera de realizar esta acción si es la más extendida actualmente

pese a que en ocasiones se trate a SOAP como un nuevo lenguaje de programación, no es más que

un conjunto de normas que hacen uso de XML, una definición de la composición del documento,

de sus partes y de sus contenidos.

Realmente de lo que se encarga SOAP es decir cómo se deben empaquetar los datos para que

puedan ser transmitidos interpretados por otro usuario, marcara las directrices acerca de cómo se

deben posicionar los datos y como definir el significado cada uno de ellos.

Cada conjunto de datos SOAP empaquetados correctamente se denomina mensaje, es decir con el

uso de los servicios web, se está definiendo un área de trabajo controlada por mensajes, e la que

cada uno de ellos transmite información que implica la realización de una o varias acciones.

Como protocolos de transporte entre emisor y receptor del mensaje SOAP, puede usarse cualquiera

de los protocolos soportados por internet de manera estándar (HTTP. SMTP. FTP) o incluso sin

ser estándares(Jabber). Según, (Loquerica, 2003)

5.2 MENSAJE SOAP

 28

Los elementos centrales del protocolo para crear un mensaje SOAP son los siguientes:

 Envelope.

Es el momento raíz del documento XML que lo identifica como un mensaje SOAP.

 Header.

La cabecera es opcional y puede contener cero o más bloques, llamados header block, que

pueden contener información de control o procesamiento para que el mensaje pueda ser

tratado por los nodos a lo que va destinado. En cierto modo, esta es una manera de extender

la funcionalidad del protocolo.

 Body.

Este elemento es obligatorio y contiene la información que se desea transmitir al receptor.

 Fault.

Contiene información explicativa de los errores que hayan podido ocurrir.

A la hora de intercambiar mensajes SOAP (da lo mismo que sea del cliente al servidor al cliente)

se tienen que tener en cuenta tres características esenciales:

 Los mensajes SOAP son unidireccionales.

 Los mensajes SOAP se suelen cambiar formando patrones.

 Las implementaciones de mensajes SOAP tienen que estar totalmente optimizadas (se

obtienen mejor beneficio de la red, protocolo de comunicación, con lo que se trabaje).

El mensaje SOAP será, un documento que contendrá los datos necesarios para realizar una llamada

a un servicio. Entre la información contenida en estos datos figuran aspecto tan importante como

el nombre de la función a la que se quiere llamar y los parámetros que sean necesarios para realizar

dicha llamada.
 29

Al igual que en la llamada al servicio, en la respuesta de este, también se usará un documento

SOAP, que contendrá entre otros datos, la información correspondiente al resultado de la ejecución

de la función demandada en el documento de llamada. Según, (Lequerica, 2003, p. 63)

El lugar de SOAP en la pila de tecnología de servicios web es como un protocolo de empaquetado

estandarizado para los mensajes compartidos por las aplicaciones. La especificación no define

nada más que una simple envoltura basada en XML para la información que se transfiere, y un

conjunto de reglas para traducir los tipos de datos específicos de la aplicación y la plataforma en

representaciones XML.

El diseño de SOAP lo hace adecuado para una amplia variedad de mensajes de aplicación y

patrones de integración. Esto, en su mayor parte, contribuye a su creciente popularidad. Según

(Snell , Tidwell, & Kulchenko , 2002, p. 11)

SOAP es un protocolo que permite la intercomunicación máquina-maquina, mediante llamadas a

métodos:

 Desarrollado en 1998 por Dave Winer y otros, con respaldo de Microsoft.

 SOAP comenzó siendo un protocolo privado de Microsoft, lo que provoco la aparición de

un protocolo muy similar, pero libre, XML-RPC.

 Normalmente emplea HTTP, aunque también soporta otros protocolos como SMTP y RSS.

 SOAP intercambia documentos XML, tanto para los distintos métodos como para los datos.

 Los métodos no forman parte de SOAP, sino que los define el programador de la

aplicación.

 Similar a RPC, pero más sencillo al basarse en mensajes HTTP.

 30

 SOAP especifica exactamente como codificar las cabeceras HTTP y los documentos XML

para intercambiar toda la información.

Según, (Carlos, 2016, pp. 11-12)

5.3 Características de los API REST y SOAP

El principal beneficio de SOAP recae en ser fuertemente acoplado, lo que permite poder ser

testeado y depurado antes de poner en marcha la aplicación. En cambio, las ventajas de la

aproximación basada en REST recaen en la potencial escalabilidad de este tipo de sistemas, así

como el acceso con escaso consumo de recursos a sus operaciones debido al limitado número de

operaciones y el esquema de direccionamiento unificado.

A modo de resumen, veamos las características de ambas aproximaciones en la siguiente tabla:

REST SOAP

 Las operaciones se definen en los  Las operaciones son

mensajes. definidas como puertos

 Una dirección única para cada instancia WSDL.

Características del proceso.  Dirección única para todas

 Cada objeto soporta las operaciones las operaciones.

estándares definidas.  Múltiples instancias del

 Componentes débilmente acoplados. proceso comparten la

misma operación.

 Componentes fuertemente

acoplados.
 31

 Bajo consumo de recursos.  Fácil (generalmente) de

 Las instancias del proceso son utilizar.

creadas explícitamente.  La depuración es posible.

Ventajas  El cliente no necesita información  Las operaciones

declaradas de enrutamiento a partir de la URI complejas pueden ser

inicial. escondidas detrás de una

 Los clientes pueden tener una fachada.

interfaz “listener” (escuchadora)  Envolver APIs existentes

genérica para las notificaciones. es sencillo.

 Generalmente fácil de construir y  Incrementa la privacidad.

adoptar.  Herramientas de

desarrollo.

 Gran número de objetos.  Los clientes necesitan

 Manejar el espacio de nombres (URIs) saber las operaciones y su

puede ser engorroso. semántica antes del uso.

Posibles  La descripción sintáctica -semántica  Los clientes necesitan

desventajas muy informal (orientada al usuario). puertos dedicados para

 Pocas herramientas de desarrollo. diferentes tipos de

notificaciones.
 32

 Las instancias del proceso

son creadas

implícitamente.

Tabla 1: Características de los API REST y SOAP

Fuente: (Elaboración Propia)

5.4 Diferencias entre API REST y SOAP

La principal diferencia entre REST y SOAP se resume en los siguientes puntos de vista del

propósito de la Web:

Según, (Marset, 2006-2007, pp. 4-14)

A modo de resumen, veamos las diferencias entre REST y SOAP, desde varios puntos de vista en

la siguiente tabla:

REST SOAP

 Solamente existen los elementos  Es un estilo de arquitectura orientado

HTTP y está orientado a recursos. a RPC.

 No permite el uso estricto de  Al ser orientador RPC, los servicios

Diferencias sesión pesto que por definición es Web crean sesiones para invocar a

sin estado. los métodos remotos.

 Propone HTTP como nivel de  Utiliza HTTP como un túnel por el

aplicación. que pasa sus mensajes, se vale de

 33

XML para encapsular datos y

funciones en los mensajes.

 Interacción dirigida por el usuario  Flujo de eventos orquestados.

por medio de formularios.  Muchas operaciones con pocos

 Pocas operaciones con muchos recursos.

recursos.  Falta de un mecanismo de nombrado

Tecnología  Mecanismos consistentes de  Se centra en el diseño de aplicaciones

nombrado de recursos (URI). distribuidas.

 Se centra en la escalabilidad y

rendimiento a gran escala para

sistemas distribuidos hipermedia.

 XML: auto descriptivo.  Tipado fuerte, XMl Schema

 HTTP.  Independiente del trasporte.

Protocolo  HTTP: es un protocolo de  HTTP es un protocolo de trasporte.

aplicación.  Síncrono y Asíncrono

 Síncrono.

 Confía en documentos orientados  WDSL.

al usuario que define las  Se puede construir automáticamente

Descripción direcciones de petición y las stubs (clientes) por medio de WDSL.

del servicio respuestas.  Tipado fuerte.

 WDSL 2.0
 34

 Interactuar con el servicio supone

horas de testeado y depuración de

URIs.

 No es necesario el tipado fuerte, si

ambos lados están de acuerdo con

el contenido.

 WADL propuesto en noviembre

de 2006.

 Los recursos contienen datos y  El servidor puede mantener el estado

enlaces representado transiciones de conversación.

a estados válidos.  Los mensajes solo contienen datos.

Gestión del  Los clientes mantienen el estado  Los clientes mantienen el estado

estado. siguiendo los enlaces. suponiendo el estado de servicio.

 Técnicas para añadir sesiones:  Técnicas para añadir sesiones:

Cookies. Cabecera de sesión (no estándar)

 HTTPS.  WS-Segurity.

 Implementado desde hace  Las implementaciones están

Seguridad muchos años. comenzando a aparecer ahora.

 Comunicación punto a punto y  Comunicación origen a destino

segura. segura.
 35

 Identificar recursos a ser  Listar las operaciones del servicio en

expuestos como servicios. el documento WDSL.

 Definir URLS para  Definir un modelo de datos para el

direccionarlos. contenido del mensaje.

Metodología  Distinguir los recursos de solo  Elegir un protocolo de transporte y

de diseño. lectura (GET) de los modificables definir correspondientes políticas

(POST, PUT, DELETE). QoS, de seguridad y transaccional.

 Implementar e implantar el  Implementar e implantar el

servicio Web. contenedor del servicio Web.

 Fue creado en el año 2000 por  Fue creado en 1998 por Dave

Roy Fielding en UC, Irvine. Winer et al. En colaboración con

 Desarrollado en un académico Microsoft.

Origen. medio ambiente, este  Desarrollado por una gran

protocolo abraza la filosofía empresa de software, este

de abrir la web protocolo aborda el objetivo de

abordar las necesidades de la

empresa mercado.
 36

 Cuando los clientes y  Cuando los clientes necesitan

servidores operan en un tener acceso a los objetos

entorno web. disponibles en servidores.

Cuando usar  Cuando la información sobre  Cuando quieren aplicar un

los objetos no necesita ser contrato formal entre el cliente y

comunicado al cliente. servidor

 Cuando necesita hacer  Cuando quieres que la mayoría

cumplir un contrato estricto de desarrolladores usen

Cuando no entre el cliente y servidor. fácilmente tu API.

usar  Al realizar transacciones que  Cuando tu ancho de banda es

implican llamadas múltiples muy limitado.

 Servicios de redes sociales.  Servicios financieros.

 Redes sociales.  Vía de pago.

Casos de uso  Servicios de chat web.  Servicio de telecomunicaciones.

 Servicios móviles.
 37

 Use REST si está enfocado en  Use SOAP si está tratando con

Conclusiones adopción de API a gran escala operaciones transaccionales y

o si su API está dirigido a usted ya tiene una audiencia que

aplicaciones móviles. es satisfecho con esta tecnología.

Tabla 2: Diferencias entre API REST y SOAP

Fuente: (Elaboración propia)

6. CONCLUSIONES

 En definitiva, observamos que las ventajas e inconvenientes del desarrolla basado en API

REST están muy relacionados. Lo que puede comenzar como una ventaja puede suponer

una desventaja en otro punto de tu aplicación. Sin embargo, como hemos dicho, existen

muchas situaciones en las que desarrollar basados en un API nos puede aportar un gran

adelanto.

 Cabe mencionar que REST ha estado tomando fuerza a una velocidad impresionante y más

con la llegada de NodeJS y las bases de datos NoSQL como MongoDB. Sin embargo, el

hecho de que REST tome fuerza, no significa que le esté quitando protagonismo a SOAP,

pues recordemos que con la llegada del Internet de las cosas (IOT) cada vez se conectan
 38

más dispositivos a internet que necesitan ser integrados (una gran oportunidad para REST)

y es donde REST está tomando la delantera.

 Podemos diseñar excelentes arquitecturas basadas en REST de una manera bastante más

sencilla.

 Los servicios SOAP se basan su comunicación bajo el protocolo SOAP o protocolo

estándar que define cómo dos objetos en diferentes procesos pueden comunicarse por

medio de intercambio de datos XML. La comunicación se realiza mediante XML, y este

aspecto es donde radican las principales diferencias contra REST.

 39

7. BIBLIOGRAFÍA

 Alvarez, Miguel Angel. (14 de Diciembre de 2014). desarrolloweb.com. Obtenido de

https://desarrolloweb.com/articulos/ventajas-inconvenientes-apirest-desarrollo.html

 BBVA l API_Market. (23 de Marzo de 2016). Obtenido de

https://bbvaopen4u.com/es/actualidad/api-rest-que-es-y-cuales-son-sus-ventajas-en-el-

desarrollo-de-proyectos

 Blancarte, O. (6 de Marzo de 2017). SOAP vs REST. Obtenido de

https://www.oscarblancarteblog.com/wp-test/2017/03/06/soap-vs-rest-2/

 CALLEJAS, M. A. (2013). Tecnologias de Programacion Integrativas. Madrid: Centro de

Estudios Ramon Areces s.a.

 Carlos, U. R. (Marzo de 2016). Apuntes dela Escuela Superior de Ingenieria de

Telecomunicaciones. Obtenido de https://gsyc.urjc.es/~mortuno/st/antecedentes_rest

 Flores, C. A. (9 de Diciembre de 2012). Soap vs Rest. Obtenido de

http://carlosmayta.blogspot.com/

 Galan, H. G. (31 de 08 de 2016). Arsys. Obtenido de

https://www.arsys.es/blog/programacion/proyectar-un-backend-hoy/

 JOSE VILLAR CUELI, FEDERICOHUERCANO RUIZ. (s.f.). Implementacion e

Integracion de Elementos software con Tecnologias Basadas en Componentes. ic editorial.

 Lequerica, J. R. (2003). Web Services.

 Luna, F., Claudio, P., & Lacano , M. (s.f.). PROGRAMACION WEB Full Stack Web apps

y plataformas amigables. RedUsers.

 40

 Manuel, A. C. (s.f.). Tecnologias y programacion integrativas. Madrid: CENTRO DE

ESTUDIOS RAMON ARECES S.A.

 Marset, R. N. (2006-2007). Modelado, Diseño e implementacion de Servicios Web.

 Snell , J., Tidwell, D., & Kulchenko , P. (2002). PROGRAMMING WEB SERVICES WITH

SOAP. United State of America: Colleen Gorman.