¿Qué es una API REST? Fundamentos para Ingenieros de Redes

Mientras exploraba los Learning Tracks en Cisco DevNet pude notar rápidamente que el API más popular y mas utilizado en sus nuevas plataformas es el API de REST. Así que sin perder mucho tiempo decidí estudiar REST. Empecé a partir desde la perspectiva de un diseñador de API en general y un diseñador de API REST. El primer objetivo fue entender cuales son las bondades que este ofrece que han hecho que sea popularmente implementado en plataformas de programabilidad y automatización de redes. Los demás objetivos, fueron enfocados en aprender lo que a continuación les estaré compartiendo.

Introducción

Llegada la nueva era de la Programabilidad de las Redes, Automatización y SDN, se ha hecho necesario que los ingenieros en redes aprendan programación. La programación permite desarrollar herramientas de software que puedan comunicarse con plataformas de redes. Estas herramientas se crean con el objetivo de facilitar y automatizar las tareas de los ingenieros.

La comunicación entre las herramientas de softwares y las plataformas de redes se da gracias a que los fabricantes han habilitado mejores interfaces de programación de aplicaciones o API por sus siglas en ingles. Entre las plataformas de redes la API REST ha sido una de las mas populares. Por esta razón es importante conocer los fundamentos teóricos y prácticos de esta API.

Partiremos desde la definición misma de un API hasta llegar hasta los mecanismos de seguridad que se pueden implementar.

¿Qué es una API?

Una API es una interfaz, una puerta de acceso por la cual una aplicación puede comunicarse con otras aplicaciones. Esta ofrece una manera simple para conectar, integrar y extender sistemas de software sin importar en que lenguaje de programación fue desarrollada una aplicación.

Las APIs son comúnmente utilizadas para construir Sistemas de Softwares Distribuidos cuyos componentes están ligeramente acoplados.

Para los desarrolladores de aplicaciones lo atractivo de una API es que provee una interfaz reusable, que permite que diferentes aplicaciones puedan conectarse de una manera fácil. Esta característica posibilita que productos de softwares empresariales puedan interconectarse con otros productos, dando paso a nuevas formas de crear negocios rápidamente.

Grandes compañías como Google, Facebook y Amazon tienen APIs desarrolladas para abrir al mundo oportunidades de crear nuevos productos o expandir las funcionalidades de un producto existente. Tenemos el ejemplo de Uber quienes sacan provecho de las APIs de Google Maps para sus mapas.

Estilo Arquitectónico REST

Antes de definir lo que es una API REST, es importante conocer el concepto del Estilo Arquitectonico REST.

En general, un estilo arquitectónico es un diseño de una solución predefinida. Aplicar un estilo arquitectónico permite construir una API mucho más rápida y más consistente.

El estilo arquitectónico REST define un conjunto de restricciones y acuerdos arquitectónicos, cuyo diseño hace un uso óptimo del protocolo HTTP y todas su bondades. 

Algunas de las restricciones que este impone son:

• Usar las capacidades de HTTP lo más posible.
• Diseñar Recursos(Nombres), no Métodos.
• Utilizar los métodos de HTTP los cuales tienen una semántica bien especificada.
•  Comunicación sin estado entre cliente y servidor.
•  Utilizar el enfoque acoplamiento ligero e independencia de solicitudes.
•  Emplea los Códigos de Estados de HTTP para las respuestas a solicitudes.
• Usa MIME/Media Types.

No se preocupen, al principio cuesta entender estas restricciones. Entenderlas requiere de conocer conceptos que veremos mas adelante.

Estas restricciones tan dependientes al protocolo HTTP hacen que nos preguntemos, ¿Por qué REST utiliza HTTP como modelo para definir su estilo arquitectónico? La respuesta es simple, el éxito de las Web basadas en HTTP proveen una prueba viviente de la escalabilidad y longevidad de estas arquitecturas.

En resumen, lo mas importante es tener claro que REST no es un estándar, tampoco es un protocolo, mas bien es un estilo arquitectónico compuesto de acuerdos y restricciones basados en el protocolo HTTP.

Ventajas de REST

Cada una de sus restricciones contribuye a una propiedad deseable del sistema:

• Escalabilidad en el sistema. Como los sistemas REST son sin estados y las solicitudes independiente, es posible escalar fácilmente el sistema con sólo agregar nuevos servidores.
• Las solicitudes independientes y sin estados también permiten tolerancia a fallas, mejorando la disponibilidad y la confiabilidad del sistema completo. 
• La funcionalidad de Caching puede ser alcanzada de gratis, ya que puede hacer uso de la existente infraestructura de HTTP, tal como HTTP Caches.
• Es compatible con el manejo de múltiples tipos de contenido. Una API puede entregar el recurso en múltiples representaciones alternativas, y el cliente puede leer las respuestas en solo una de estas representaciones.

REST hace fácil crear una excelente experiencia a los desarrolladores de API y también a los consumidores.

Entonces, ¿Qué es una API REST?

Dentro de una aplicación, software o servicio, una API REST es una interfaz o puerta, desarrollada teniendo en cuenta los acuerdos y restricciones definidos por el protocolo HTTP, para permitir que otras aplicaciones se comuniquen para crear, leer, actualizar o eliminar información.

Conozcamos ahora los componentes de REST en una descripción corta que mas adelante vamos a expandir.

Recursos. Un recurso es un elemento de información que puede ser accedido e identificado a través de un Identificador de Recursos Uniforme o URI por sus siglas en inglés. Para manipular estos recursos el cliente y servidor utilizan una interfaz uniforme de HTTP, con la cual se intercambian representaciones de estos recursos.

Uniform Resource Identifier(URI). Una URI es una dirección de un recurso, es decir indica la ubicación del recurso dentro del servidor que lo contiene. También el URI es el identificador del recurso. El URI puede ser llamado como URL(Uniform Resource Locator). Ambos términos son intercambiables.

Ejemplo de un URI: https://api.codnova.com/routers

Representaciones. Se conoce como representación a un recurso mostrado en un formato definido. En REST un recurso puede estar disponible en múltiples representaciones, tales como en formato JSON y en XML.

Interfaz Uniforme de HTTP. Todos los recursos utilizan la misma interfaz uniforme, la cual puede ser utilizada para ejecutar operaciones en los recursos. Una Interfaz Uniforme HTTP define las operaciones CRUD para crear, leer, actualizar y borrar recursos. Las Operaciones CRUD están definidas por los métodos de HTTP POST(Create), GET(Reading), PUT(Updating) y DELETE(Deleting).

Recursos

Un recurso es un elemento de información que puede ser accedido e identificado a través de un Identificador de Recursos Uniforme o URI por sus siglas en inglés. Para manipular estos recursos el cliente y servidor utilizan una interfaz uniforme de HTTP, con la cual se intercambian representaciones de estos recursos.

Entender un recurso a veces requiere de visualizar ejemplos, así que veamos la siguiente imagen donde tenemos dos recursos.

Como ya vimos un recurso se identifica exclusivamente por su Identificador de Recursos Uniformes o URI.  Imaginemos que tenemos una red compuesta de dos routers , donde definimos cada router como un recurso. Cada Router puede ser identificado con los siguientes URIs:

Router 1
URI: https://codingnetworks.blog/routers/1 

Router 2
URI: https://codingnetworks.blog/routers/2

Categorías de Recursos

Existen diferentes categorías de recursos que se diferencian por su composición.

Recurso Colección

Un recurso colección consiste en una lista de recursos donde todos los recursos son del mismo tipo.  Por ejemplo una lista de routers.

{
      “Routers”: [ 
                   { 
                     “Hostname”: “R1” 
                     “Vendor”: “Cisco” 
                     “Id”: “1” 
                   }, 
                   { 
                     “Hostname”: “R2” 
                     “Vendor”: “Huawei” 
                     “Id”: “2” 
                   }
                ]
}

Este recurso colección se puede identificar con el siguiente URI: https://codingnetworks.blog/routers

El acceso a una colección de recursos típicamente contiene modificadores para filtrar recursos por una propiedad en específico o para comparar los recursos por características similares.

Un ejemplo utilizando el recurso routers, sería buscar un recurso de la colección filtrando por el hostname del recurso:

GET https://codingnetworks.blog/routers?hostname=R1

Recurso instancia

Representa un simple objeto. Dentro del recurso colección “routers”,  un router es un recurso instancia.

{
    “Hostname”: “R1”
    “Vendor”: “Cisco”
    “Id”: “1”
}

Este recurso instancia se puede identificar con el siguiente URI : https://codingnetworks.blog/routers/1

Recurso controlador

Representa un proceso que corre una o múltiples tareas.  Cómo ya hemos mencionado una importante restricción de REST es que solo se pueden utilizar los métodos estándares de HTTP(GET, PUT,etc), por lo tanto cuando se desea ejecutar un proceso más complejo se utilizan este tipo de recursos.

Mediante un método estándar de HTTP y una serie de parámetros se describe la funcionalidad que convoca dentro del servidor un proceso programado. Por ejemplo un simple método pudiera disparar un proceso que elimine todos los routers inactivos dentro de una lista. 

Este recurso controlador se puede identificar con el siguiente URI:
https://codingnetworks.blog/routers/inactiveRoutersRemoval

Los recursos controlador normalmente al convocarse retornan un recurso de estado el cual permite al cliente dar seguimiento al estado del proceso convocado.  El recurso de estado debería incluir campos tales como el estado actual, tiempo estimado de la ejecución del proceso, entre otros.

Un ejemplo de un recurso de estado puede ser:
URI: https://codingnetworks.blog/routers/duplicateRemoval/212010

Al consultar al servidor sobre el estado de este recurso con el método GET se puede obtener la información del progreso del proceso y el tiempo estimado para completación.

Ejemplo:
GET https://domain.com/routers/duplicateRemoval/212010

Response: 200 OK
{
  “Progress: “20%”,
  “Estimated_time_to_completion” : “ 5 min 4 sec”
}

Identificador de Recursos Uniformes o URI

Un URI es definido por el RFC 3986 como un identificador compuesto de una secuencia de caracteres o componentes que siguen una sintaxis definida. A continuación vamos a descomponer un URI para entender las funciones de cada uno de sus componentes.

Ejemplo: https://codingnetworks.blog:80/routers/1?hostname=R1&vendor=Cisco

• “https”. Especifica el protocolo a utilizar para acceder al recurso.
• “codnova.com”. Identifica el servidor o host donde se encuentra el recurso.
• “80”. Especifica el numero del puerto por el cual el servidor o host está esperando que entren las solicitudes.
• “/routers/1”. Indica la ruta del recurso dentro del servidor.
• “?hostname=R1&vendor=Cisco”. Son un conjunto de parámetros que permiten realizar una búsqueda o filtrado de un recurso.
• Caracteres especiales utilizados para separar los componentes:
  • “://”. Se utiliza para separar el protocolo(http) del host(codnova.com).
  • “:”. Se utiliza para separar el host(codnova.com) del numero de puerto lógico(80).
  • “/”. Se utiliza para separar jerárquicamente los recursos y sus componentes.
  • “,” ó “;”. Se utilizan para separar recursos no jerárquicos.
  • “-” ó “_”. Se utilizan para estructurar recursos con nombres largos.
  • “?”. Se utiliza para separar la ruta del recurso de los parámetros de búsqueda o filtrado.
  • “&”. Si existen múltiples parámetros de búsqueda o filtrado se utiliza para separarlos entre si.

Representaciones

Una representación es una serialización de un recurso. Un recurso es meramente datos en bruto. Para transferir un recurso entre la API REST y el cliente, se necesita primero serializarlo, es decir codificarlo en un formato acordado entre ambas partes. Por lo tanto las representaciones no son mas que recursos serializados que son transmitidos entre cliente y API.

Para serializar un recurso en una representación y para deserializar la representación de vuelta en un recurso, hay que seguir un conjunto de reglas de serialización. En HTTP, los MIME-Types pueden ser usados como Reglas de Serialización. JSON y XML son reglas de serialización comúnmente usados para crear representaciones.

Cuando una representación es enviada via HTTP, la podemos encontrar en el cuerpo de la solicitud y respuesta del paquete HTTP. En la cabecera de HTTP se especifican las reglas de serialización utilizadas para crear la representación. El campo Content-Type de la cabecera HTTP es el utilizado para especificar las reglas de serialización. Para una representacion JSON, el valor sería “application/json”.

Las reglas de serialización son especificadas acorde a un entandar llamado Multipurpose Internet Mail Extensions(MIME), definido en el RFC 2045 de la IEFT. Las reglas de serialización, especificadas acorde al estandar MIME son llamadas MIME-Type(Content-Type). Un ejemplo de esta regla según el estandar es la que ya mencionamos para JSON, llamada “application/json”.

Parámetros

Una API REST típicamente no retorna datos estáticos, en cambio retorna datos dinámicos que dependen de entradas provistas por el cliente o consumidor. Una API puede recibir entradas vía el Cuerpo de HTTP y vía parámetros de HTTP.

Vamos a ver a continuación los casos en los que se provee de entradas a un API vía parámetros.

Creación y Actualización de un Recurso

Cuando se crea un recurso nuevo, los campos de este nuevo recurso necesitan ser completados con valores iniciales. Estos valores son enviados como entradas al API.

Si el recurso es creado con el método POST, los valores iniciales para los campos del recurso son transferidos como Parámetros Formularios.

Los Parámetros Formularios son pares Llaves-Valor, donde la llave es el nombre del parámetro y Valor es el valor del parámetro. Veamos el siguiente ejemplo en el cual tenemos las llaves(hostname y vendor) y los valores(R1 y Cisco).

POST  https://codingnetworks.blog/routers?hostname=R1&vendor=cisco

Si un recurso es creado o actualizado con el método PUT, la entrada de datos es enviada como una representación vía el Cuerpo de HTTP.

{
    “Hostname”: “R1”
    “Vendor”: “Cisco”
    “Id”: “1”
}

Recuperación de un Recurso: Filtrado y Ordenación

Ya sabemos que un recurso colección es un conjunto de recursos del mismo tipo. Hay ocasiones donde un cliente solo está interesado en un pequeño grupo de la colección. La API REST ofrece una funcionalidad para filtrar una colección, buscar en una colección y ordenar una colección.

Los filtros son configurados comúnmente a través de criterios de filtrados. Ordenar requiere de especificar el criterio de ordenación . Esto se puede expresar a través de Parámetros de Consultas.

Los Parámetros de Consultas son pares Llave-Valor que son adjuntados al URI del recurso. Múltiples parámetros de consultas pueden ser concatenados, formando una lista.

Una consulta de Ordenado sería:

GET  https://codingnetworks.blog/routers?sort=hostname&sortOder=desc

Recuperación de un Recurso: Localizadores

Los localizadores proveen información para identificar un recurso, tal como el URI. En REST, los localizadores son normalmente presentados como Parámetros de Ruta. Los Parámetros de Ruta en un URI representan un recurso.

Los Parámetros de Rutas son parte del URI y por lo tanto se vuelve parte del Identificador del Recurso.

Recuperación de un Recurso: Proyecciones

Hay situaciones en las que los clientes no quieren toda la información que contiene un recurso. La API REST ofrece una funcionalidad para limitar los campos del recurso que quieres recibir.

Las proyecciones permiten seleccionar campos y solo incluir estos en la respuesta. Estos proveen una visión parcial del recurso. Las proyecciones pueden aplicarse a Recursos Colección y Recursos de Instancia. Algunos ejemplos serían:

Proyección en Recurso Colección
GET  https://codingnetworks.blog/routers?fields=hostname

Proyección en Recurso Instancia
GET  https://codingnetworks.blog/routers/1/hostname
or
GET  https://codingnetworks.blog/routers/1?fields=hostname

Múltiples Campos
GET  https://codingnetworks.blog/routers/1?fields=hostname, vendor

Parámetros de Cabecera

Parámetros Genéricos de la Cabecera

Los parámetros de cabecera genéricos son aquellos que pueden utilizarse tanto en el mensaje de Solicitud al API como en el mensaje de Respuesta de este. Vamos a definir algunos de los más comunes:

• Content-Type: Indica cual es la sintaxis y semántica del Cuerpo de HTTP. También es conocido como MIME-Type.
• Content-Length: Indica la longitud del contenido en Bytes. Permite que el receptor verifique si ha recibido el contenido completo.
• Content-Language: Especifica el lenguaje de la Representación, usando un código de dos letras de acuerdo al RFC 5646.
• Content-Location: Indica la dirección en la cual el contenido del Cuerpo de HTTP puede ser recuperado con un GET. Esto lo que indica que el cuerpo HTTP contiene una copia del recurso, cuya dirección es dada en el Content-Location Header. 
• Content-Encoding: Indica el método de compresión utilizado. Los valores permitidos son: gzip, compress o deflate.
• Content-MD5: Contiene un Hash del contenido para verificar la integridad de este.
• Date: Es una etiqueta que contiene el tiempo de cuando la solicitud fue enviada.
• Host: Indica cual es el Host o destino a ser contactado.

Parámetros de la Cabecera de Solicitud

En adición a los Parámetros Genéricos de Cabezera, los Parametros de solicitud mas comunes que se envía en una Solicitud hacia el API son:

• User-Agent: Identificador del Cliente.
• Referer: Especifica el formulario de URL donde se obtuvo el URL de la solicitud actual.
• Expect: Indica el Codigo de Estado esperado por el cliente.
• From: Contiene una dirección de correo del Usuario que envía la solicitud.
• Max-Forward: Máximo numero de saltos en una Solicitud TRACE.
• Accept: Especifica una lista de tipos de medios(Media-Types), que el Usuario Agente puede aceptar como respuesta.
• Accept-Charset: Especifica un conjunto de caracteres, que el Usuario Agente puede aceptar como respuesta.
• Accept-Enconding: Especifica una codificación, que el Usuario Agente puede aceptar como respuesta.
• Accept-Language: Especifica los lenguajes, que el Usuario Agente puede aceptar como respuesta.
• MIME-Version: Especifica la versión del protocolo MIME que es utilizado.

Parámetros de la Cabecera de Respuesta

Los siguientes parámetros son utilizados normalmente en la respuesta que es enviada desde el API a los clientes:

• Status: Contiene el Código de Estado HTTP, indicando Exitoso o razón de la falla.
• Retry-After: Indica que tanto debe el Usuario Agente esperar antes de reenviar una solicitud. Tipicamente son usados en combinación de un Codigo de Estado 5XX.
• Location: Indica el URL del recurso, el cual es relevante para esta respuesta.
• Allow: Lista todos los metodos que pueden ser usados con un respectivo recurso .
• Server: Tal como la cabecera User-Agent, permite identificar el Software que fue usado para producir la solicitud. La cabecera Server identifica el software y versión que fue usado para reproducir la respuesta.
• Vary: Especifica cuales cabeceras de Solicitud influyen en la solección de la Representación durante la Negociación.
• Age: Especifica al cantidad de tiempo que ha pasado desde que la Respuesta fue generada.
• Cache-Control . Es seleccionado por el API y es el principal control para el Caching. Permite la configuración de múltiples directivas:
  • The Max-age
  • No-cache directive
  • Public directive
  • Private directive
  • Must-revalidate directive.
• Date: Especifica cuando la eespuesta fue enviada y ayuda a los clientes a computar el Tiempo de refrescamiento.

Códigos de Estado

Cuando un método es ejecutado en un recurso HTTP, este como respuesta retorna al menos un código de estado, que básicamente indica el éxito o fracaso de la operación. Es con este código que el cliente determina los siguientes pasos a seguir.

Para cada uno de estos casos de éxito o error, el Código de Estado HTTP es definido como un código numérico y una descripción corta.

El código de estado numérico está compuesto por 3 dígitos. El primer dígito agrupa los Códigos de Estados en 5 grupos:

Códigos de Estado Informacionales (1xx) : Información No Crítica.

Código de Estado	Mensaje del Estado	Significado
100	Continue	Indica que la parte inicial de la Solicitud fue recibida.

Códigos de Estado de Éxito(2xx) : La solicitud fue procesada exitosamente.

Código de Estado	Mensaje del Estado	Significado
200	OK	La Solicitud fue procesada exitosamente
201	Created	Indica que uno o mas recursos fueron creados
202	Accepted	Indica que la solicitud ha sido aceptada para procesarse pero el proceso no ha terminado.
203	Non-Authoritative Information	Indica que la solicitud fue exitosa, pero que el Payload ha sido modificado por un Proxy.
204	No Content	Indica que la solicitud fue exitosa pero que el Cuerpo de HTTP no contiene una respuesta.

Códigos de Estado de Redirección (3xx): El cliente tiene que hacer otra solicitud basada en los parámetros de la cabecera recibida en la respuesta.

Código de Estado	Mensaje del Estado	Significado
300	Multiple Choices	Múltiples recursos coincidieron con la consulta realizada.
301	Moved Permanently	Redirecciona la consulta a la dirección especificada.

Códigos de Estado de Error en el Cliente (4xx): Un error ha ocurrido. El cliente es responsable del problema.

Código de Estado	Mensaje del Estado	Significado
400	Bad Request	Sintaxis Incorrecta en la Solicitud.
401	Unauthorized	Solicitud fallida, usuario no autenticado.
402	Insufficients Funds	Fondos insuficientes. Para APIs Monetizados.
403	Forbidden	Solicitud fallida, usuario no tiene autorización para acceder al recurso.
404	Not Found	El recurso no fue encontrado.
405	Method not Allowed	Método HTTP especificado en la solicitud no está permido.
406	Not Acceptable	El API no puede producir una respuesta con un MEdia-Type que el cliente pueda aceptar.
408	Request Timeout	Indica que el servidor no recibió una solicitud completa.
409	Conflict	Indica que hay un conflicto con el estado actual de l recurso.

Códigos de Estado de Error en el Servidor(5xx) : Un error ha ocurrido. El Servidor o API es responsable del problema.

Código de Estado	Mensaje del Estado	Significado
500	Internal Server Error	Una condición inesperada ocurrió en el API y una excepción fue arrojada.
501	Not Implemented	La funcionalidad solicitada por el cliente no esta implementada todavía.
502	Bad Gateway	El servidor que actua como Gateway o Proxy obtuvo una respuesta inbalida del Backend
503	Service Unavailable	El servidor no puede procesar la solicitud o fue rechazada la conexión.

Seguridad en un API REST

Exponer sistemas de softwares vía una API abre una gran cantidad de retos a nivel de seguridad. Por lo que como es de esperarse la API REST viene con mecanismos para tratar temas se Seguridad concernientes a:

• Autenticación
• Autorización
• Delegación
• Identidad
• Ataques

Mecanismos de Seguridad

Llaves de API

Una llave de una API es un identificador único, el cual es requerido para cada solicitud hecha al API. La llave única permite identificar al cliente y autorizarles el acceso a los Recursos que este tiene permiso de acceder. Esto quiere decir que una Llave API puede ser utilizado tanto para Autenticación como para Autorización. Por lo tanto debe mantenerse confidencial.

La llave API es generada y administrada por la plataforma de interacción API y la plataforma de tiempo de ejecución API. La plataforma de interacción API generalmente corre como portal de autoservicio.

Al llamar a la API, el cliente proporciona la llave de API como parámetro en la solicitud. La plataforma API Runtime verifica la llave API proporcionada en la base de datos de llaves API. Con este proceso se autentica al consumidor de API y se autoriza la solicitud verificando que la API consultada está en el conjunto de APIs que esta llave tiene permitido acceder.

En términos generales, las llaves API proporcionan un mecanismo ligero para la autenticación y autorización de clientes API.

HTTP Basic

HTTP Basic es un mecanismo simple para la autenticación y autorización de una solicitud de API. Es ampliamente utilizado, ya que es compatible con muchas bibliotecas y servidores HTTP. El cliente API primero solicita las credenciales API en la plataforma de interacción API, y las usa cuando realiza una llamada API, proporcionando nombre de usuario y contraseña en el encabezado de Autorización de HTTP.

HTTP Digest

El resumen, HTTP Digest sigue los mismos principios que HTTP básico, pero es un poco más seguro. Utiliza un mecanismo de desafío-respuesta, que consta de los siguientes pasos:

OAuth

OAuth es un estándar para delegar autorizaciones, está estandarizado en IETF RFC 6749. Con OAuth, un usuario final obtiene un token de acceso de la API y puede proporcionarlo a cualquier aplicación de terceros o aplicación simple delegando así sus derechos de acceso a esta aplicación . El token representa los derechos de acceso para un subconjunto de datos, por un corto período de tiempo.

Algunos API REST

A continuación les comportado unas cuantas API REST gratuitas que utilizan diferentes mecanismos de seguridad.

No Security/Open

• https://restcountries.eu/#api-endpoints

Oauth

• https://developers.google.com/gmail/api/
• https://developer.spotify.com/

API Key

• https://developers.zomato.com/api

Conclusión

Espero que hayan podido aprender un poco mas sobre los API REST. Cualquier pregunta o comentario la pueden escribir mas abajo. Es bienvenida toda palabra que ayude a mejorar y enriquecer este contenido.