- Servicio Web
- Servicio web XML
- Servicio web SOAP
- Servicio web WSDL
- Servicio web REST
Servicio Web.
Un Web Service, o Servicio Web, es un método de comunicación entre dos aparatos electrónicos en una red. Es una colección de protocolos abiertos y estándares usados para intercambiar datos entre aplicaciones o sistemas. Las aplicaciones escritas en varios lenguajes de programación que funcionan en plataformas diferentes pueden utilizar web services para intercambiar información a través de una red. La interoperatividad, por ejemplo entre Java y Python o Windows y Linux se debe al uso de estándares abiertos.
Como sistema de mensajes se utiliza XML estandarizado. El protocolo más simple para el intercambio de información entre ordenadores es XML-RPC, que emplea XML para llevar a cabo RPCs. RPC, Remote Procedure Call, es un protocolo de red que permite a un programa a ejecutar código en una máquina remota. Los XML-RPC requests son una combinación entre contenido XML y headers HTTP. La simpleza de los XML-RPC hizo que el estándar evolucionase a SOAP, uno de los componentes básicos de los Web Services.
La base de comunicación entre web services es por tanto el lenguaje XML y el protocolo HTTP.
Servicio Web XML.
Los servicios Web XML son un conjunto de aplicaciones o de tecnologías con capacidad para interoperar en la Web. Estas aplicaciones o tecnologías intercambian datos entre sí con elmobjetivo de ofrecer unos servicios. Los proveedores ofrecen sus servicios como procedimientos remotos y los usuarios solicitan un servicio llamando a estos procedimientos a través de la Web, por lo que estos servicios deben estar alojados en un servidor Web. Los servicios Web XML permiten el manejo distribuido de componentes, estos permiten tomar ventaja de la infraestructura de Internet para la distribución de funcionalidad y paquetes de datos. Las principales características de los servicios Web XML son:
- Están basados en protocolos estándar para la Web. Los servicios Web XML realizan las peticiones y proporcionan las respuestas utilizando protocolos estándar de la Web, como los son HTTP (Hyper Text Transfer Protocol), XML (Extensible Markup Language), y SOAP (Simple Object Access Protocol), toda plataforma que maneje dichos protocolos, podrá aprovechar la funcionalidad de los servicios Web XML.
- Comunicación de aplicación a aplicación basada en Internet. Al utilizar un servicio Web XML no se tienen una interfaz de usuario visible; realmente se trata de un componente que puede ser consumido de manera programática de aplicación a aplicación. Los servicios Web XML proporcionan una interfaz estándar para la recepción de peticiones y envío de respuesta, denominada contrato, dicho contrato pone a disposición de los usuarios la información requerida por el componente, describe los comportamientos del mismo, y relaciona los datos de entrada con la salida del componete.
- Independencia del lenguaje. Los servicios Web XML pueden ser consumidos desde programas escritos en cualquier lenguaje .NET, por lo cual no es necesario aprender un lenguaje determinado para poder tener acceso a su funcionalidad.
- Independencia de la plataforma. Independientemente de la plataforma que dispongan los clientes de una aplicación, el contrato se encarga de hacer la petición en un formato estándar, y de recibir la respuesta correspondiente.
- Arquitectura libre del manejo de estados (stateless architecture). Los servicios Web XML no manejan estados de objetos; cada respuesta brindada por un servicio Web XML es una nueva instancia de un objeto, con su estado particular. Lo que una petición realiza no impacta lo realizado por otras peticiones.
- Comunicación síncrona y asíncrona. El requerimiento de ejecución de un método de servicio Web XML, y el requerimiento de la respuesta, son independientes. La aplicación que consume el servicio Web XML, y el servicio Web XML mismo, pueden operar con mayor disponibilidad, ya que liberan recursos mientras se está en tiempo de espera.
- Las aplicaciones intercambian datos entre sí en un medio ambiente seguro usando XML signature y XML encryption, XML signature ofrece servicios de integridad y autenticación de mensajes para los datos, XML encryption es el proceso para codificar datos de tal manera que usuarios no autenticados no puedan entenderlos.
Los principales usos que tienen los servicios Web XML son los siguientes:
- Cuando se requiere compartir funcionalidad libre de interfaz de usuario. Los servicios Web son útiles en cuando se desea consumir la funcionalidad de un componente, sin la intermediación de una interfaz de usuario. Ejemplos de esto es el consumo de servicios que proporcionan información, como tipos de cambio, estado del clima, precios de productos, disponibilidad de lugares en eventos, sin tener que responder a alguna interfaz de usuario.
- Cuando se quiere comercializar un servicio de uso de software, y no un producto de software. En el futuro, no se venderá software, sino la funcionalidad que el software brinda estará disponible como servicio en la Web.
- Cuando el equipo cliente y servidor requieren compartir funcionalidad en Internet, pero difieren en su plataforma operativa.
Ejemplo:
<?xml version="1.0"?>
<contact-info>
<contact1>
<name>Tanmay Patil</name>
<company>TutorialsPoint</company>
<phone>(011) 123-4567</phone>
</contact1>
<contact2>
<name>Manisha Patil</name>
<company>TutorialsPoint</company>
<phone>(011) 789-4567</phone>
</contact2>
</contact-info>Servicio Web SOAP.
Se trata de un protocolo derivado de XML que nos sirve para intercambiar información entre aplicaciones.
Normalmente utilizaremos SOAP para conectarnos a un servicio e invocar métodos remotos, aunque puede ser utilizado de forma más genérica para enviar cualquier tipo de contenido. Podemos distinguir dos tipos de mensajes según su contenido:
- Mensajes orientados al documento: Contienen cualquier tipo de contenido que queramos enviar entre aplicaciones.
- Mensajes orientados a RPC: Este tipo de mensajes servirá para invocar procedimientos de forma remota (Remote Procedure Calls). Podemos verlo como un tipo más concreto dentro del tipo anterior, ya que en este caso como contenido del mensaje especificaremos el método que queremos invocar junto a los parámetros que le pasamos, y el servidor nos deberá devolver como respuesta un mensaje SOAP con el resultado de invocar el método.
Puede ser utilizado sobre varios protocolos de transporte, aunque está especialmente diseñado para trabajar sobre HTTP.
Dentro del mensaje SOAP podemos distinguir los siguientes elementos:
- Un sobre (Envelope), que describe el mensaje, a quien va dirigido, y cómo debe ser procesado. El sobre incluye las definiciones de tipos que se usarán en el documento. Contiene una cabecera de forma opcional, y el cuerpo del mensaje.
- Una cabecera (Header) opcional, donde podemos incluir información sobre el mensaje. Por ejemplo, podemos especificar si el mensaje es obligatorio (debe ser entendido de forma obligatoria por el destinatario), e indicar los actores (lugares por donde ha pasado el mensaje).
- El cuerpo del mensaje (Body), que contiene el mensaje en si. En el caso de los mensajes RPC se define una convención sobre como debe ser este contenido, en el que se especificará el método al que se invoca y los valores que se pasan como parámetros. Puede contener un error de forma opcional.
- Un error (Fault) en el cuerpo del mensaje de forma opcional. Nos servirá para indicar en una respuesta SOAP que ha habido un error en el procesamiento del mensaje de petición que mandamos.
Hemos visto como los mensajes SOAP nos sirven para intercambiar cualquier documento XML entre aplicaciones. Pero puede ocurrir que necesitemos enviar en el mensaje datos que no son XML, como puede ser una imagen. En ese caso tendremos que recurrir a la especificación de mensajes SOAP con anexos.
Los mensajes SOAP con anexos añaden un elemento más al mensaje:
- El anexo (Attachment), puede contener cualquier tipo de contenido (incluido el XML). De esta forma podremos enviar cualquier tipo de contenido junto a un mensaje SOAP.
Nuestro mensaje podrá contener tantos anexos como queramos.
Un ejemplo de mensaje SOAP es el siguiente:
<SOAP-ENV:Envelope <SOAP-ENV:Body> <area>Alicante</area> </ns:getTemperatura> </SOAP-ENV:Body></SOAP-ENV:Envelope> |
En él estamos llamando a nuestro método getTemperatura para obtener información meteorológica, proporcionando como parámetro el área de la que queremos obtener la temperatura.
Servicio Web WSDL.
WSDL (Web Services Description Language) es un lenguaje basado en XML utilizado para describir la funcionalidad que proporciona un servicio Web. Una descripción WSDL (fichero WSDL) de un servicio web proporciona una descripción entendible por la máquina (machine readable) de la interfaz del servicio Web, indicando cómo se debe llamar al servicio, qué parámetros espera, y qué estructuras de datos devuelve.
La versión actual de WSDL es la 2.0, en la que se ha cambiado el significado de la D por Definition. La nueva versión plantea cambios de nomenclatura y estructura del fichero xml que contiene la descripción del servicio. En este módulo vamos a utilizar la versión anterior, la 1.1, puesto que es la que está soportada actualmente por Netbeans, así como por BPEL, que estudiaremos más adelante. En la figura siguiente mostramos la estructura que siguen los ficheros WSDL en ambas versiones, en donde podemos observar el cambio de nomenclatura en la versión 2.0.
WSDL describe un servicio utilizando varios elementos (etiquetas xml). Dichos elementos podemos clasificarlos como abstractos o concretos.La parte WSDL abstracta describe las operaciones y mensajes con detalle. En otras palabras, la parte abstracta de un WSDL especifica QUÉ hace el servicio:
- Qué operaciones están disponibles
- Qué entradas, salidas, y mensajes de error tienen las operaciones
- Cuáles son las definiciones de los tipos para los mensajes de entrada, salida y error
En el mundo Java, podemos pensar en la parte abstracta de un WSDL como en la definición de una interfaz o una clase abstracta, con la definición de sus métodos, pero no sus implementaciones. La parte abstracta de un WSDL contiene dos componentes principales:
- Las operaciones que forman la definición de la interfaz
- Los tipos de datos para los parámetros de entrada, salida y error, de las operaciones
La parte WSDL concreta describe el cómo y dónde del servicio:
- Cómo tiene que llamar un cliente al servicio
- Qué protocolo debería usar
- Dónde está disponible el servicio
En el mundo Java podemos pensar en la parte concreta de un WSDL como en la implementación de la parte abstracta, aunque en términos de servicios Web, solamente describe dónde se encuentra dicha implementación para utilizarse. La parte concreta de un WSDL contiene dos componentes principales:
- Información de enlazado (binding) sobre el protocolo a utilizar
- La dirección en donde localizar el servicio
Vamos a ver con un poco más de detalle los elementos WSDL (tanto la parte abstracta como la concreta):
- definitions: Es el elemento raiz y permite especificar el espacio de nombres del documento target namespace, el nombre, y otros prefijos utilizados en el documento WSDL. Un ejemplo de definición de prefijo es: xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/". Este prefijo especifica que todos los elementos dentro del documento de esquemas con el target namespace "http://schemas.xmlsoap.org/wsdl/" tendrán el prefijo wsdl.
- types: Se utiliza para definir los tipos de datos que se intercambiarán en el mensaje. Podemos definir dichos tipos directamente dentro de este elemento, o importar la definición de un fichero de esquema (fichero xsd). La definición de tipos puede verse como las definiciones Java de clase, con variables que pueden ser tipos primitivos o referencias a otras clases u objetos. Los tipos primitivos se definen en los espacios de nombres del Schema y normalmente nos referimos a ellos como built-in types. Éstos incluyen tipos simples tales como string, int, double,...
- message: Define los distintos mensajes que se intercambiaran durante el proceso de invocación del servicio. Se deberán definir los mensajes de entrada y salida para cada operación que ofrezca el servicio. Los mensajes muestran descripciones abstractas de los datos que se van a intercambiar.
- portType: Contiene una colección de una o más operaciones. Para cada operación indica cuáles son los mensajes de entrada y salida, utilizando para ello los mensajes definidos en el apartado anterior. Los portTypes son, por lo tanto, colecciones abstractas de operaciones soportadas por un servicio
- binding: Indica el protocolo de red y el formato de los datos para las operaciones de un portType. Los bindings son definiciones concretas de los portTypes. Un portType puede tener múltiples bindings asociados. El formato de datos utilizado para los mensaje de las operaciones del portType puede ser orientado al documento u orientado a RPC. Si es orientado al documento tanto el mensaje de entrada como el de salida contendrán un documento XML. Si es orientado a RPC el mensaje de entrada contendrá el método invocado y sus parámetros, y el de salida el resultado de invocar dicho método, siguiendo una estructura más restrictiva.
- service: Define el servicio como una colección de elementos port a los que se puede acceder. Un port se define asociando una dirección de red con un binding, de los definidos en el documento. Dicha dirección de red es la dirección (URL) donde el servicio actúa, y por lo tanto, será la dirección a la que las aplicaciones deberán conectarse para acceder al servicio.
Un documento WSDL de ejemplo es el siguiente:
<?xml version="1.0" encoding="utf-8"?> <types> <xsd:schema> schemaLocation= </xsd:schema> </types> <message name="sayHello"> <part name="parameters" element="tns:sayHello"/> </message> <message name="sayHelloResponse"> <part name="parameters" element="tns:sayHelloResponse"/> </message> <portType name="Hello"> <operation name="sayHello"> message="tns:sayHello"/> <output wsam:Action= message="tns:sayHelloResponse"/> </operation> </portType> <binding name="HelloPortBinding" type="tns:Hello"> style="document"/> <operation name="sayHello"> <soap:operation soapAction=""/> <input> <soap:body use="literal"/> </input> <output> <soap:body use="literal"/> </output> </operation> </binding> <service name="HelloService"> <port name="HelloPort" binding="tns:HelloPortBinding"> <soap:address location= </port> </service></definitions> |
En este ejemplo se define un servicio, denominado HelloService. Dicho servicio está formado por el port HelloPort, al cual se accede con protocolo http (binding transport=http) y con mensajería soap con estilo document (binding style=document). Dicho port proporciona la operación (funcionalidad) sayHello (operation name= "sayHello"). Dicha operación utiliza la codificación literal en los mensajes de entrada y salida (body use= "literal"). Esto es lo que se conoce como operación de tipo document/literal.
El elemento portType define la operación sayHello a partir de los mensajes de entrada y salida que la componen.
En los elementos message vemos la descripción de los mensajes de entrada y salida de la operación sayHello. El mensaje de entrada contiene un dato de tipo "tns:sayHello", y el de salida es de tipo "tns:sayHelloResponse" (la cadena de saludo devuelta por el servicio). La definición de los tipos se encuentra en el fichero de esquema referenciado por la propiedad schemaLocation en una sub-etiqueta de <types>
Servicio Web Rest.
Qué es una API
- Es una forma de describir la forma en que los programas o los sitios webs intercambian datos.
- El formato de intercambio de datos normalmente es JSON o XML.
¿Para qué necesitamos una API?
- Ofrecer datos a aplicaciones que se ejecutan en un movil
- Ofrecer datos a otros desarrolladores con un formato más o menos estándar.
- Ofrecer datos a nuestra propia web/aplicación
- Consumir datos de otras aplicaciones o sitios Web
Provedores de APIs
- Algunos ejemplos de sitios web que proveen de APIS son:
- Twitter: acceso a datos de usuarios, estado
- Google: por ejemplo para consumir un mapa de Google
- Pero hay muchos más: Facebook, YouTube, Amazon, foursquare...
- Pero todavía hay muchos más: directorio de proveedores de APIs
Qué significa API REST
- REST viene de, REpresentational State Transfer
- Es un tipo de arquitectura de desarrollo web que se apoya totalmente en el estándar HTTP.
- REST se compone de una lista de reglas que se deben cumplir en el diseño de la arquitectura de una API.
- Hablaremos de servicios web restful si cumplen la arquitectura REST.
- Restful = adjetivo, Rest = Nombre
Como funciona REST
Llamadas al API
Las llamadas al API se implementan como peticiones HTTP, en las que:
- La URL representa el recurso
http://www.formandome.es/api/cursos/1
- La URL representa el recurso
El método (HTTP Verbs) representa la operación:
GET http://www.formandome.es/api/cursos/1
- El código de estado HTTP representa el resultado:
200 OK HTTP/1.1
404 NOT FOUND HTTP/1.1
Creación de recursos
- La URL estará “abierta” (el recurso todavía no existe y por tanto no tiene id)
- El método debe ser POST
http://eventos.com/api/eventos/3/comentarios
Respuesta a la creación de recursos
- Resultados posibles:
- 403 (Acceso prohibido)
- 400 (petición incorrecta, p.ej. falta un campo o su valor no es válido)
- 500 (Error del lado del servidor al intentar crear el recurso, p.ej. se ha caído la BD)
- 201 (Recurso creado correctamente)
- ¿Qué URL tiene el recurso recién creado?
- La convención en REST es devolverla en la respuesta como valor de la cabecera HTTP Location
Actualización de recursos
- Método PUT
- Según la ortodoxia REST, actualizar significaría cambiar TODOS los datos
- PATCH es un nuevo método estándar HTTP (2010) pensado para cambiar solo ciertos datos. Muchos frameworks de programación REST todavía no lo soportan
- Resultados posibles
- Errores ya vistos con POST
- 201 (Recurso creado, cuando le pasamos el id deseado al servidor)
- 200 (Recurso modificado correctamente)
Eliminar recursos
- Método DELETE
- Algunos resultados posibles:
- 200 OK
- 404 Not found
- 500 Server error
- Tras ejecutar el DELETE con éxito, las siguientes peticiones GET a la URL del recurso deberían devolver 404
Arquitectura REST
Reglas de una arquitectura REST
- Interfaz uniforme
- Peticiones sin estado
- Cacheable
- Separación de cliente y servidor
- Sistema de Capas
- Código bajo demanda (opcional)
Interfaz Uniforme
- La interfaz de basa en recursos (por ejemplo el recurso Empleado (Id, Nombre, Apellido, Puesto, Sueldo)
- El servidor mandará los datos (vía html, json, xml...) pero lo que tenga en su interior (BBDD por ejemplo) para el cliente es transparente
- La representación del recurso que le llega al cliente, será suficiente para poder cambiar/borrar el recurso:
- Suponiendo que tenga permisos
- Por eso en el recurso solicitado se suele enviar un parámetro Id
Interfaz uniforme: mensajes descriptivos
- Mensajes descriptivos:
- Usar las características del protocolo http para mejorar la semántica:
- HTTP Verbs
- HTTP Status Codes
- HTTP Authentication
- Procurar una API sencilla y jerárquica y con ciertas reglas: uso de nombres en plural
- Usar las características del protocolo http para mejorar la semántica:
Peticiones sin estado
- http es un protocolo sin estado ---> mayor rendimiento
GET mi_url/empleados/1234
DELETE mi_url/empleados/1234
- En la segunda petición hemos tenido que incidar el identificador del recurso que queremos borrar
- El servidor no guardaba los datos de la consulta previa que tenía el cliente en partícular.
- Una petición del tipo DELETE mi_url/empleado debe dar error, ¡falta el id y el servidor no lo conoce!
Cacheable
- En la web los clientes pueden cachear las respuestas del servidor
- Las respuestas se deben marcar de forma implícita o explícita como cacheables o no.
- En futuras peticiones, el cliente sabrá si puede reutilizar o no los datos que ya ha obtenido.
- Si ahorramos peticiones, mejoraremos la escabilidad de la aplicación y el rendimiento en cliente (evitamos principalmente la latencia).
Separación de cliente y servidor
- El cliente y servidor están separados, su unión es mediante la interfaz uniforme
- Los desarrollos en frontend y backend se hacen por separado, teniendo en cuenta la API.
- Mientras la interfaz no cambie, podremos cambiar el cliente o el servidor sin problemas.
Sistema de capas
- El cliente puede estar conectado mediante la interfaz al servidor o a un intermediario, para el es irrelevante y desconocido.
- Al cliente solo le preocupa que la API REST funcione como debe: no importa el COMO sino el QUE
- El uso de capas o servidores intermedios puede servir para aumentar la escalabilidad (sistemas de balanceo de carga, cachés) o para implementar políticas de seguridad
Código bajo demanda (opcional)
- Los servidores pueden ser capaces de aumentar o definir cierta
funcionalidad en el cliente transfiriéndole cierta lógica que pueda
ejecutar:
- Componentes compilados como applets de Java
- JavaScript en cliente.
Consejos para elaborar una API REST
Versiones del API
- Los cambios en el código no deberían afectar al API
- Si hay cambios en el API se deben usar versiones para no fustrar a los desarrolladores
- La mejor opción es añadir un prefijo a las URLS:
GET /v1/geocode HTTP/1.1
Host: api.geocod.io
GET /v2/geocode HTTP/1.1
Host: api.geocod.io
HTTP verbs
- Si realizamos CRUD, debemos utilizar los HTTP verbs de forma adecuada para cuidar la semántica.
- GET: Obtener datos. Ej: GET /v1/empleados/1234
- PUT: Actualizar datos. Ej: PUT /v1/empleados/1234
- POST: Crear un nuevo recurso. Ej: POST /v1/empleados
- DELETE: Borrar el recurso. Ej: DELETE /v1/empleados/1234
- ¿PATCH?: Para actualizar ciertos datos
Nombre de los recursos
- Plural mejor que singular, para lograr uniformidad:
- Obtenemos un listado de clientes: GET /v1/clientes
- Obtenemos un cliente en partícular: GET /v1/clientes/1234
- Url's lo más cortas posibles
- Evita guiones y guiones bajos
- Deben ser semánticas para el cliente
- Utiliza nombres y no verbos
- Estructura jerárquica para indicar la estructura: /v1/clientes/1234/pedidos/203
Códigos de estado
- Se utilizan los códigos de estado de http
- Si realizamos un request de POST deberemos devolver un 201.
- Se pueden producir múltiples errores en la llamada al API:
- falta de permisos
- errores de validación
- O incluso un error interno de servidor.
- Siempre se debe devolver un código de estado HTTP con los requests.
- Añadir un mensaje de error si es necesario.
Formato de salida
- En función de la petición nuestra API podría devolver uno u otro formato.
- Nos fijaremos en el ACCEPT HEADER
GET /v1/geocode HTTP/1.1
Host: api.geocod.io
Accept: application/json
*GET /v1/geocode HTTP/1.1
Host: api.geocod.io
Accept: application/xml
- En principio utilizaremos JSON: sencillo y simple
- XML no es nuestro amigo: schemas, namespaces...
- Si no es un requerimiento, evitaremos XML
Algunos ejemplos de Servicios API REST
- Google Maps
- Google Translate
- GitHub
- Wikipedia
- ChatCompos
Frameworks que se pueden emplear para desarrollar aplicaciones web basadas en servicios:
Frameworks Web y móviles Descripción Angular.js Un framework basado en JavaScript react Liberado por Facebook, en JavaScript, permite desarrollar aplicaciones móviles para IOS y Android ionic Para móviles, usando HTML, Js, Sass y Angular Meteor En JavaScript, para web y móviles Ruby on Rails Framework MVC basado en Ruby, orientado al desarrollo de aplicaciones web CodeIgniter Poderoso framework PHP liviano y rápido Kohana Un fork de CodeIgniter, Gracias a Samuel por mencionarlo en los comentarios. Django Framework Python que promueve el desarrollo rápido y el diseño limpio CakePHP Framework MVC para PHP de desarrollo rápido Zend Framework Framework para PHP 5, simple, claro y open-source Yii Framework PHP de alto rendimiento basado en componentes Pylons Framework web para Python que enfatiza la flexibilidad y el desarrollo rápido Catalyst Framework para aplicaciones web MVC elegante Symfony Framework full-stack TurboGears Próxima generación construido sobre Pylons Aprendizaje:
Aprendí mas sobre los servicios web y su funcion en nuestra carrera, ademas de enteder los conceptos fundamentales del mismo, tambien que gracias a los estandares abiertos haya intercambios de comunicacion aunque ambas esten en otro sistema operativo u hechas en un lenguaje de programacion distinto, en los servicios web nos encontramos varias ramas, (si se les ouede decir así) como son: XML, SOAP, WDSL Y REST, cada uno tiene su funcionalidad pero siguen siendo Servicios web, tambien tomamos en cuenta que se hace uso de los protocolos web y pues a final tenemos los servicios web REST, que tiene como caracteristicas: Ofrecer datos a aplicaciones que se ejecutan en un movil, Ofrecer datos a otros desarrolladores con un formato más o menos estándar, Ofrecer datos a nuestra propia web/aplicación y Consumir datos de otras aplicaciones o sitios Web , que ses lo que vamos a hacer durante el cuatrimestre en curso.
Francisco Alexis Navarro Lucero
Referencias y/o apoyo:
- https://diego.com.es/introduccion-a-los-web-services
- https://www.tutorialspoint.com/es/xml/xml_databases.htm
- https://programacionwebisc.wordpress.com/5-1-vision-general-de-servicios-web-xml/
- http://www.jtech.ua.es/j2ee/publico/servc-web-2012-13/sesion01-apuntes.html#Servicios+Web+SOAP+y+Java+EE
- https://desarrolloweb.com/articulos/que-es-rest-caracteristicas-sistemas.html
- https://juanda.gitbooks.io/webapps/content/api/arquitectura-api-rest.html
- https://www.redhat.com/es/topics/api/what-are-application-programming-interfaces
- https://elbauldelprogramador.com/los-10-mejores-frameworks-gratis-de-aplicaciones-web/
