SERVICIOS WEB

Los servicios web se describen como una tecnología cuyo propósito principal es conectar
programas de software entre sí a través de puntos distantes en Internet, transportando grandes
cantidades de datos de manera más eficiente y económica. “Los servicios web funcionan a un nivel
de abstracción similar a Internet y son capaces de unir cualquier sistema operativo, plataforma de
hardware o lenguaje de programación1” (Pavan Kumar, 2011, p.2).

Esta herramienta surgió debido a la necesidad de compartir recursos de software y hardware

distribuidos en sistemas de computadoras que corrían de manera secuencial y aislada; una vez que
se logró interconectar estos sistemas se pudieron alcanzar objetivos comunes. Esto significó, la
necesaria incorporación de software adicionales de sincronización y por lo tanto, la posibilidad de
escalar a mayores niveles de productividad y complejidad en los sistemas.

Algunas tecnologías intentaron solucionar eficientemente la interconexión entre sistemas aislados y

compartir recursos, por ejemplo, CORBA (Common Object Request Broker Architecture2), fue una
de las primeras que surgió para facilitar el desarrollo de aplicaciones distribuidas en entornos
heterogéneos pero actualmente SOAP y REST son las que dominan de mercado.

Un servicio web en su forma más simple sirve de marco de comunicación entre una computadora
“cliente” y el “servidor”. Estos equipos se comunican a través de internet, donde el primero envía
una solicitud al segundo, la cual lo recibe, la procesa y devuelve al cliente la respuesta. Es lo que se
conoce como modelo Cliente-Servidor, según Pavan Kumar (2011) “Un servicio web consiste
principalmente en un servidor y un cliente. El servidor proporciona servicios definidos a través de la
Web a los clientes3” (p.1). Dichas solicitudes pueden venir de una aplicación de escritorio, una
pagina web, un dispositivo móvil, o una aplicación embebida, podrían estar en ejecución en un
ordenador, un teléfono, una Tablet o incluso en una heladera conectada a internet, pueden ser
codificados en cualquier lenguaje de programación soportado ya que lo que importa es que se
envíen las peticiones correctamente al servicio web.

Una página web se vale del "servicio web" para proporcionar una GUI (interfaz gráfica de usuario)
adecuada a los requerimientos de datos de los clientes. Un sitio web y un servicio web son entidades
bien diferenciadas ya que la primera se usa por ejemplo para escuchar música, comprar y acceder al
clima, pero que no sería posible realizarlo sin el acceso a un servicio remoto ofrecido por un
servidor. Considérese un sitio web de compras en línea con funcionalidades diversas como agregar
ítems a un carrito de compras; dichos elementos serán procesadas a través de una tarjeta de crédito

1
Traducción propia del Autor
2
En español, Arquitectura Común de Agente de Solicitud de Objetos
3
Traducción propia del Autor
para su cancelación. En dicho sitio, este servicio web de pago consiste en una integración con una
entidad bancaria a la cual se le hace una petición de disponibilidad en la TDC para poder procesar el
pedido.

Ahora bien, ha sido necesaria la estandarización de estos servicios web para que los desarrolladores
de las paginas en internet puedan normalizar sus actividades; en un esfuerzo por lograr estos
objetivos, han sido creados varios estándares conocidos como los W3C (World Wide Web
Consortium4), los cuales dentro de sus funciones esta la de “Guiar la Web hacia su máximo
potencial a través del desarrollo de los protocolos y pautas que aseguren el crecimiento futuro de la
Web” (Salazar, 2013, p.18). Dentro de sus estándares se encuentra el SOAP.

Una de las clasificaciones más comunes de los Servicios Web los divide en dos tipos: Servicios
Web Grandes y Servicios Web REST (Representational State Transfer). Los Servicios Web
Grandes, funcionan bajo un protocolo denominado SOAP (Simple Object Access Protocol), el cual
posibilita la comunicación mediante el intercambio de mensajes XML (Extensible Markup
Language) muy estructurados. Este tipo de servicios web permite mantener estados en el
servidor, de manera que agracia la realización de operaciones complejas.

REST
REST es el acrónimo de Representational State Transfer5, la cual hace referencia a “un estilo de
arquitectura de software que brinda pautas para la creación de servicios web basados en recursos”
(Makkonen, 2017, p. 3). Por lo que no se puede confundir con ningún patrón de diseño, ni asociarse
con el uso particular de un protocolo de comunicación; REST representa una filosofía de desarrollo
que colecciona un serie de principios y técnicas que son definidas en un conjunto de restricciones.

En este sentido, Fielding (2000) plantea este estilo de arquitectura para desarrollar software de una
forma diferente que requiere ciertas etapas de diseño antes de realizar su implementación normal en
un proyecto, esas fases se componen de varios niveles la cual comienza con la llamada “Etapa del
Caos” que es donde se hacen las definiciones iniciales y se determinan los protocolos de
comunicación, los formatos del mensaje, entre otros. Después viene la etapa de “Definición de
Recursos”, donde se describen las entidades importantes del sistema que tendrán una función
específica dentro de la aplicación y que se activan al recibir una petición de parte de los clientes,
luego de recibir estas solicitudes a través de los métodos HTTP tales como GET, PUT, POST y
DELETE, se producen las respuestas y son enviadas al dispositivo que los requirió. Seguidamente,
el tercer nivel es el conocido como HATEOAS la cual usa el hipertexto del núcleo del estado de la
aplicación, la cual básicamente significa el acople de recursos para satisfacer necesidades de los

4
Traducción en español, El consorcio WWW
5
Traducción en español, transferencia de estado representacional
clientes, pero dicho acople se realice utilizando URLS que permitirán un recorrido o
desplazamiento hacia otros recursos relacionados.

Una arquitectura que cumple con REST no desperdicia sus capacidades ni subutiliza sus recursos ni
su potencial, por lo que, debe cumplir con todos los factores de éxito para que la web sea mucho
mas eficiente en el manejo de la información. Los servicios web tipo REST se pueden describir
según Pavan Kumar (2011) a través del concepto abstracto “recursos” que puede ser accedido
mediante un URI (uniform resource identifier6).

REST ve todo como un recurso, y…un recurso es cualquier cosa que sea lo
suficientemente importante como para ser referenciada como una cosa en sí misma, como
un archivo almacenado en una computadora, software, un atributo en una tabla de base
de datos…Los recursos pueden ser estáticos o dinámicos...Las páginas web estáticas, por
ejemplo, no cambian si el mismo usuario o un usuario diferente lo vuelven a solicitar.
Las páginas web dinámicas podrían cambiar y, a diferencia de las estáticas, no se pueden
almacenar en caché. Cada recurso debe tener al menos un URI (identificador uniforme de
recursos) para representarlo. REST se refiere a esto como representación de recursos.
URI es la dirección web del recurso y hace que el recurso esté disponible en línea. Un
recurso puede ser accedido / referenciado por su URI7 (p. 25).
Una aplicación debe estar correctamente direccionada para que esté disponible en línea. Por
ejemplo, una casa y su dirección son análogas a un recurso en línea y su URI. Se puede ubicar una
casa a través de su dirección, de la misma forma en que debe direccionarse un recurso para que esté
disponible en línea. Entonces, al buscar algo en línea con un motor de búsqueda y el recursos está
direccionado, el motor de búsqueda lo recogerá.

API REST

Para utilizar los servicio web es necesario conocer el concepto de API (Application Programming
Interface), que es la interface de programación de aplicaciones y se define como “..una herramienta
mediante la cual las funciones de un sistema en particular se hacen disponibles en otros ambientes
de programación, permitiendo una interacción más sencilla y uniforme” (Manzanares Márquez,
2012, p.9)

También otros autores lo definen como:

…un conjunto de comandos, funciones y protocolos informáticos que permiten a los

desarrolladores crear programas específicos para ciertos sistemas operativos. Las API
simplifican en gran medida el trabajo de un creador de programas, ya que no tiene que
«escribir» códigos desde cero. Estas permiten al informático usar funciones predefinidas
para interactuar con el sistema operativo o con otro programa. (abc, 2018, p.1)
Este concepto se refiere a los procedimientos y funciones a través de las cuales un servidor web se
comunica con librerías o aplicaciones. La aplicación que los desarrolladores crean y recopilan

6
Traducción en español, identificador de recursos uniforme
7
Traducción propia del autor
información de los servicios alojados en la red o de otras aplicaciones, como por ejemplo, cuando
alguien quiere desarrollar una agenda telefónica con todos los contactos existentes en una ciudad,
no se necesitaría llenar toda la información en la agenda con esa data, pues ya hay un servicio que
hace tiene estas funciones, y solo se requiere que la aplicación se limite a realizar la solicitud de esa
información. Se refiere entonces, a que las APIs permiten la comunicación con otras librerías que
generalmente son llamados recursos y los significa que hubo ya un desarrollador que hizo todo el
código, a decir la parte más compleja y sólo expuso u otorgó a los otros desarrolladores ciertas
funciones que les van a permitir acceder a esa información.

Ahora bien, la sintaxis necesaria para las solicitudes de servicios, se hacen a través de cualquiera de
los formatos XML o JSON, dependiendo de la tecnología que se esté usando, dichos formatos están
provistos de identificadores URI (Uniform Resource Indentificator) que permiten diferenciar y
encontrar los recursos dentro de internet, a decir: “Es un sistema global que condensa la Dirección
Uniform Resource Locator (URL) y el Uniform Resource Name (URN) del recurso para
identificarlo dentro de la red y de esta forma tener mayor efectividad en su recuperación” (Corrales
Rubiano y López Herrera, 2007, p.2). En este sentido, las URIS son un componente muy importante
en las APIs que incluye a las URL y también a las URN, pero ambas identifican recursos a través de
una localización lógica. Es importante considerar dentro de la solicitud que hagan los clientes, el
tipo de dato que se envía, así como también los valores de los parámetros.

Las acciones dentro de un API REST, están determinada por los verbos GET, PUT, POST,
DELETE y PATH, que antes de ser ejecutados, es necesario considerar el nivel de seguridad que el
servidor posee, y para ello habría que analizar la autenticación que en su forma básica esta
conformada por un nombre de usuario y una contraseña, pero pueden ser mas robusta e incluir token
de seguridad. Además, un desarrollador puede implementar en sus aplicaciones clientes un servicio
web siempre y cuando se sepa cómo conectarse con la API sin necesidad de saber como funciona el
servidor. En este sentido, no importa si el servicio está en PHP, ASP.NET o en definitiva en
cualquier otro lenguaje siempre que pueda llamarse al servicio web desde el lado del cliente. No es
necesario que el cliente conozca detalle alguno de la implementación de la API, es decir, no importa
el lenguaje de programación, bases de datos u otras tecnologías en que está basado el entorno del
servidor, ya que este esconde su complejidad detrás de sus códigos encapsulados y abstraídos en las
funcionalidades ofrecidas al cliente y nada más.

Una de las ventajas de las API REST, es la capacidad de separación del recursos y su
representación. Partiendo de que un recurso es simplemente un conjunto de información
representado por JSON o XML, el servidor es el encargado de devolver una respuesta adecuada
según el tipo de representación. Si la petición HTTP en su cabecera o header especifica que el
contenido requerido debe venir en XML, y el servidor no es compatible con ese lenguaje, entonces
éste devolverá un error “500” especificando un evento inesperado. Sin embargo, cuando la solicitud
pasa a través de una API REST, la función de esta sería precisamente resolver estas
incompatibilidades de lenguaje y el servidor no se preocupa por eso, dejando la responsabilidad de
transformación a la API misma.

Referencias Bibliográficas
 abc. (2018). ¿Qué es una API y para qué sirve?. [online] Available at:
http://www.abc.es/tecnologia/consultorio/20150216/abci--201502132105.html [Accessed 14
Feb. 2018].
 Andrade, G., Borzone, E. and Muñoz, A. (2015). Seguridad en Internet con los certificados
SSL y HTTPS. Ingeniería. Universidad Técnica Federico Santa María.
 Betík, B. (2010). XML Data Visualization. Ingeniería. Charles University in Prague.
 Bersack, E. (2000). Implementation of a hypertext transferprotocol server on a high
assurance multilevelsecure platform. Ingeniería. Naval Postgraduate School. Monterey,
California.
 Blog.santiagobasulto.com.ar. (2018). HATEOAS: ¿qué y por qué? · Santiago Basulto | Blog.
[online] Available at: http://blog.santiagobasulto.com.ar/rest/2012/09/27/rest-apis-
hateoas.html [Accessed 13 Feb. 2018].
 Cambera, J. (2009). COMPOSICIÓN DE SERVICIOS WEB PARA APLICACIONES
MÓVILES GEOLOCALIZADAS. Ingeniería. UNIVERSIDAD SIMÓN BOLÍVAR.
 Chillarón, C. (2015). Desarrollo de un Sistema de Recogida de Datos en Facebook
Aplicando Gamificación. Ingeniería. Universidad Autónoma de Madrid.
 Corrales Rubiano, A. and López Herrera, C. (2007). Identificadores Digitales: Una
Herramienta Que Apoya La Recuperación De Información. Revista signos.
 Corredor Ceballos, N. (2017). Estado Del Arte Revisión Sistemática De La Seguridad
Orientada A Rest. Ingeniería. Universidad Católica de Colombia.
 Facebook for Developers. (2018). Información general - API Graph de Instagram -
Documentación - Facebook for Developers. [online] Available at:
https://developers.facebook.com/docs/instagram-api/overview/?locale=es_LA [Accessed 13
Feb. 2018].
 Fielding, R. (2000). Architectural Styles and the Design of Network-based Software
Architectures. Doctorado. UNIVERSITY OF CALIFORNIA.
 Garcia Peña, F. (2015). Estudi de les API RESTFUL. Ingeniería. Universitat Politècnica de
Catalunya.
 Grigoraş, D. (2005). Using XTM for navigating UDDI. Doctorado. University of Osnabrück,
Germany and University of Twente, The Netherlands.
 Jossie Zambrano, E. (2012). Aplicaciones en Internet. Universidad Central de Venezuela.
Lecturas en Ciencias de la Computación.
 Luna, F., Peña Millahual, C. y Iacono, M. (2018). PROGRAMACION WEB Full Stack 22 -
Web apps y plataformas amigables: Desarrollo frontend y backend. RedUsers, 22, p.24.
 Manzanares Márquez, J. (2012). Desarrollo De Las Interfaces De Programación De
aplicación (Api) Para Myaltargetr©2.0. Ingeniería. Universidad Simón Bolívar.
 Makkonen, J. (2017). Performance and usage comparison between REST and SOAP web
services. Doctorado. Aalto University.
 OLIVA FELIPE, L. (2010). Design and development of a REST-based Web service platform
for applications integration. Doctorado. UNIVERSITAT POLITÈCNICA DE
CATALUNYA.
 Pavan Kumar, P. (2011). On the Design of Web Services: SOAP vs. REST. Licenciatura.
University of North Florida.
 PCActual.com. (2018). ¿Qué son las cookies y por qué aparecen tantos avisos en las web?.
[online] Available at: http://www.pcactual.com/noticias/actualidad/cookies-aparecen-tantos-
avisos--2_12535 [Accessed 12 Feb. 2018].
 Suda, B. (2003). SOAP Web Services. Doctorado. University of Edinburgh.
 Valdivia Caballero, J. (2016). Modelo de procesos para el desarrollo del front-end de
aplicaciones web. INTERFASES, (9).