¿Qué es un WebService?
Enviar y Recibir Información entre dispositivos

Frecuentemente me encuentro con programadores de plataforma móvil Android que desean incursionar en el desarrollo de un WebService y no saben donde comenzar o lo que deben saber para llevar a cabo esa integración.

En primer lugar hablaré de lo que significa un WebService, sus elementos y como puede ser aprovechado.

El concepto WebService surge a partir de la necesidad de conectar dos puntos dentro de la Internet. Una, la que tiene inicialmente la información (el servidor) y otra (el cliente) que recibe información en forma de consultas o envía nueva información para ser procesada o grabada por el servidor.

Pongamos un ejemplo sencillo. Lo más natural para nosotros es abrir la aplicación de Red Social. La primera vez, completamos nuestros datos de registro e ingresamos (mediante un login) a la misma. Esto no sería posible sin un WebService.

En este ejemplo existe una máquina en una remota parte del mundo que está pendiente de recibir (escuchando) una nueva conexión, recibe datos del cliente y lo procesa. Luego de este proceso, el mismo servidor envía cierta información al cliente y este cliente (en su lógica programada) genera una respuesta y evento a este dato, mostrando al usuario en pantalla la información recibida y generando una interacción.

Este WebService es simplemente un programa servidor ejecutado continuamente en una máquina esperando que otro programa cliente le envíe información en un formato y parámetros esperados.

La conexión a un WebService generalmente se invoca por medio de una URL (dirección web) tal como https://direccionweb:puerto. La dirección web puede ser un dominio ‘midominio.com’ o una IP 172.217.3.142. El ‘puerto’ es un número entero, generalmente entre 80 y 65535, que nos permite indicar específicamente la puerta de entrada de la petición de información. En la misma máquina servidor pueden estar corriendo varios WebService, a través del puerto se puede hacer esa diferenciación.

La demanda de información desde clientes (anónimos y/o desconocidos) hace que la seguridad de acceso a una red deba protegerse a través de la publicación de, solamente, cierta información.

En otras palabras, una empresa o persona solamente desea publicar cierta información y no desea que cualquier computadora se conecte a toda la información disponible dentro de la misma, para ello publica un WebService con información limitada.

¿Qué tipo de información se recibe o envía?


En este punto comienzan a volverse más complejos los requerimientos de los WebService y sus usos.

Inicialmente el concepto WebService surge por la demanda de plataformas Web requeridas por navegadores. Actualmente un WebService puede aplicarse a varios tipos de dispositivos dentro del mundo de las conexiones.

En empresas cuyas infraestructuras son complejas, constantemente se crean WebService solamente para comunicación entre distintas aplicaciones dentro de la misma red como servicios privados; otras, sin embargo, ofrecen un servicio público y otras como servicio privado-publicado.
Existen varios tipos y formatos de información transmitida entre el servidor y el cliente. Básicamente el proceso entre un cliente un servidor sucede así:

Una aplicación cliente invoca o se conecta a un servidor (se especifica un dominio o IP y puerto, https://172.217.3.142:5487/). Al establecerse la conexión el cliente está habilitado a enviar o escribir información en ese puerto.

Esta información puede escribirse como un texto simple o en formatos más complejos como XML, SOAP, REST.

Un formato XML sería…

<?xml version="1.0" encoding="UTF-8"?>
<BeginSession xmlns=”http://webservices.galileo.com">
<Profile>Simulator</Profile></BeginSession>

y su respuesta podria ser…

<?xml version="1.0" encoding="UTF-8"?>
<string xmlns=”http://webservices.galileo.com">Tyv8NKo+WiAuqQVR3H09+7QBvWWvgwIAXg4IFYGpVnZD09c4l9VXnQ/VDkxJ4oxnIyt5D/+nLzcwi/GRLSy+n646anneL1zCVOvXxN8nDiE=</string>

Para el formato simple XML, no hay una regla o lógica en la información exacta, lo que se debe enviar es información que el servidor vaya a poder procesar (entender) y devolver una respuesta que el cliente también pueda procesar.

El formato SOAP es similar…

<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope
        xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
        xmlns:xsd="http://www.w3.org/2001/XMLSchema"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <soapenv:Header>
    <ns1:RequestHeader
         soapenv:actor="http://schemas.xmlsoap.org/soap/actor/next"
         soapenv:mustUnderstand="0"
         xmlns:ns1="https://www.google.com/apis/ads/publisher/v201905">
      <ns1:networkCode>123456</ns1:networkCode>
      <ns1:applicationName>DfpApi-Java-2.1.0-dfp_test</ns1:applicationName>
    </ns1:RequestHeader>
  </soapenv:Header>
  <soapenv:Body>
    <getAdUnitsByStatement xmlns="https://www.google.com/apis/ads/publisher/v201905">
      <filterStatement>
        <query>WHERE parentId IS NULL LIMIT 500</query>
      </filterStatement>
    </getAdUnitsByStatement>
  </soapenv:Body>
</soapenv:Envelope>

Sin embargo, en este formato ya existen más elementos de información que exige el servidor para poder ser procesado. En el formato SOAP es necesario solicitar o enviar (request) la información (body) dentro un sobre (envelope), análogamente como lo haríamos con el correo tradicional. La respuesta llega en forma similar en un formato XML al cual se aplica un proceso de interpretación (parse), lo mismo que anteriormente hizo el servidor para enviarnos la información de respuesta (response).

El formato REST es un formato más simple que implica simplemente enviar palabras claves que indiquen al servidor qué tipo de acción necesitamos que procese y con qué datos.

La petición de información (request) a través de un REST generalmente se hace enviando los parámetros o información dentro de la misma dirección URL que invocamos para conectarnos.

Un ejemplo REST podría ser…

https://www.google.com/search?q=hola

Aquí le estamos pidiendo al servidor de google que haga una búsqueda (search) de la palabra (parámetro) ‘hola’. Este tipo de peticiones son llamados generalmente de tipo GET.

También existen servicios REST cuya información no es mostrada en el URL, sino que son transmitidas enviando una cadena de texto por medio de parámetros no visibles, generalmente de tipo POST o PUT.

Estas palabras mágicas GET, POST, PUT son acciones que el WebService debe interpretar y en forma coherente responder en base a estas. GET indica ‘obtener’ información. POST sugiere ‘publicar’ y PUT implica ‘escribir’ cierta información por el lado del servidor. No son las únicas acciones, existen un par mas.

API


Detrás de estas peticiones y respuestas, un WebService se establece para realizar lecturas y escrituras de una base de datos sin dar acceso directo a ellas (queremos controlar lo que quieren hacer los clientes anónimos o desconocidos). A consecuencia de este diseño surge el concepto de interfaces de conexiones entre aplicación cliente y base de datos, API (Application Programing Interface, Interfaz de Programación de Aplicaciones).

Crear una API es generalmente crear un WebService que recibe y envía información, sin embargo también existen diseños de API que no aplican directamente un WebService, sino otro tipo de conexiones o elementos (lo anotaremos para un próximo artículo).

En resumen


Un WebService es un diseño de programación como una interfaz de aplicaciones que permite a un programa cliente poder conectarse con un programa servidor, enviando y recibiendo información estructurada, ejecutar acciones y brindar información al usuario.

Los WebService pueden ser utilizados para intercambiar información entre aplicaciones dentro de una misma empresa o fuera de esta en forma privada o pública.

Actualmente existen diversos tipos de dispositivos que utilizan un WebService, páginas web, dispositivos celulares, televisores y otros con la capacidad de conectarse a Internet.

Un WebService es una forma digitalizada (una comunicación entre computadoras) del correo tradicional (una comunicación entre personas).



*