Descripción REST CCNA

REST

REST
5

Resumen

Se explica cómo REST permite las comunicaciones de equipo a equipo. ¡¡Empieza a aprender CCNA 200-301 gratis ahora mismo!!

¡Bienvenido!: Este tema forma parte del Módulo 14 del curso de Cisco CCNA 3, para un mejor seguimiento del curso puede ir a la sección CCNA 3 para guiarte del índice.

1. Vídeo – REST

Como acabas de aprender, REST es actualmente la API más utilizada. En este tema se trata REST con más detalle.

Haz clic en Reproducir en el vídeo para obtener más información sobre REST.

2. REST y RESTful API

Los navegadores web utilizan HTTP o HTTPS para solicitar (GET) una página web. Si se solicita con éxito (código de estado HTTP 200), los servidores web responden a las solicitudes GET con una página web codificada en HTML, como se muestra en la figura.

Solicitudes GET en Web
Solicitudes GET en Web

REST es un estilo arquitectónico para diseñar aplicaciones de servicio web. Se refiere a un estilo de arquitectura web que tiene muchas características subyacentes y gobierna el comportamiento de los clientes y servidores. En pocas palabras, una API REST es una API que funciona encima del protocolo HTTP. Define un conjunto de funciones que los desarrolladores pueden usar para realizar solicitudes y recibir respuestas a través del protocolo HTTP como GET y POST.

El cumplimiento de las restricciones de la arquitectura REST generalmente se conoce como “RESTful”. Una API puede considerarse “RESTful” si tiene las siguientes características:

  • Cliente/servidor – El cliente maneja el front-end y el servidor maneja el back-end. Cualquiera de los dos puede ser reemplazado independientemente del otro.
  • Sin estado – No se almacenan datos del cliente en el servidor entre solicitudes. El estado de la sesión se almacena en el cliente.
  • Cacheable – Los clientes pueden almacenar en caché las respuestas localmente para mejorar el rendimiento.

3. Implementación RESTful

Un servicio web RESTful se implementa mediante HTTP. Es una colección de recursos con cuatro aspectos definidos:

  • Identificador Uniforme de Recursos (URI, Uniform Resource Identifier) base para el servicio web, como http://example.com/resources.
  • El formato de datos admitido por el servicio web. A menudo es JSON, YAML o XML, pero podría ser cualquier otro formato de datos que sea un estándar de hipertexto válido.
  • El conjunto de operaciones admitidas por el servicio web mediante métodos HTTP.
  • La API debe estar controlada por hipertexto.

Las API RESTful utilizan métodos HTTP comunes, como POST, GET, PUT, PATCH y DELETE. Como se muestra en la tabla siguiente, esto corresponde a operaciones RESTful: Crear, Leer, Actualizar y Eliminar (o CRUD, Create, Read, Update, Delete).

Método HTTP Operación RESTful
POST Create/Crear
GET Read/Leer
PUT/PATCH Update/Actualizar
DELETE Delete/Eliminar

En la figura, la solicitud HTTP solicita datos con formato JSON. Si la solicitud se construye correctamente de acuerdo con la documentación de la API, el servidor responderá con datos JSON. La aplicación web de un cliente puede utilizar estos datos JSON para mostrar los datos. Por ejemplo, una aplicación de mapeo del smartphone muestra la ubicación de San José, California.

Implementación RESTful
Implementación RESTful

4. URI, URN, y URL

Los recursos web y los servicios web, como las API RESTful, se identifican mediante un URI. Un URI es una cadena de caracteres que identifica un recurso de red específico. Como se muestra en la figura, un URI tiene dos especializaciones:

  • Nombre Uniforme de Recurso (URN, Uniform Resource Name): Identifica solo el espacio de nombres del recurso (página web, documento, imagen, etc.) sin referencia al protocolo.
  • Localizador Uniforme de Recursos (URL, Uniform Resource Locator): Define la ubicación de un recurso específico en la red. Las direcciones URL HTTP o HTTPS se utilizan normalmente con los navegadores web. Otros protocolos como FTP, SFTP, SSH y otros pueden utilizar una URL. Una URL que utiliza SFTP puede tener el siguiente aspecto: sftp://sftp.example.com.

Estas son las partes de un URI, tal y como se muestra en la figura:

  • Protocolo/esquema: – HTTPS u otros protocolos como FTP, SFTP, mailto y NNTP
  • Nombre de host: www.example.com
  • Ruta y nombre del archivo: /author/book.html
  • Fragmento – #página155

Partes de un URI

Partes de un URI
Partes de un URI

5. Anatomía de una Solicitud RESTful

En un servicio Web RESTful, una solicitud hecha a la URI de un recurso obtendrá una respuesta. La respuesta será una carga útil (payload) típicamente formateada en JSON, pero podría ser HTML, XML, o algún otro formato. La figura muestra la URI para la API de direcciones de MapQuest. La solicitud de API es para direcciones desde San José, California a Monterey, California.

Partes de una Solicitud de API

Partes de Solicitud de API
Partes de Solicitud de API

La figura muestra parte de la respuesta de la API. En este ejemplo son las direcciones de MapQuest de San José a Monterrey en formato JSON.

Payload Parcial de JSON recibida de una Solicitud de API

Payload Parcial de JSON
Payload Parcial de JSON

Estas son las diferentes partes de la solicitud (request) de API:

  • Servidor API: Es la dirección URL del servidor que responde a las solicitudes REST. En este ejemplo es el servidor de la API de MapQuest.
  • Recursos Especifica la API que se está solicitando. En este ejemplo es la API de direcciones de MapQuest.
  • Consulta: Especifica el formato de datos y la información que el cliente solicita al servicio de API. Las consultas pueden incluir:
    • Formato: Normalmente es JSON, pero puede ser YAML o XML. En este ejemplo se solicita JSON.
    • Clave: – La clave es para autorización, si es necesario. MapQuest requiere una clave para su API de direcciones. En el URI anterior, deberás reemplazar “KEY” por una clave válida para enviar una solicitud válida.
    • Parámetros: Los parámetros se utilizan para enviar información relativa a la solicitud. En este ejemplo, los parámetros de consulta incluyen información acerca de las direcciones que necesita la API para que sepa qué direcciones devolver: “from-San+Jose,Ca” y “to-Monterey,Ca”.

Muchas API RESTful, incluidas las API públicas, requieren una clave. La clave se utiliza para identificar el origen de la solicitud a través de la autenticación. Estas son algunas razones por las que un proveedor de API puede requerir una clave:

  • Para autenticar la fuente y asegurarse de que esté autorizada para usar la API
  • Para limitar el número de personas que usan la API
  • Para limitar el número de solicitudes por usuario.
  • Para capturar y rastrear mejor los datos que solicitan los usuarios
  • Para recopilar información sobre las personas que usan la API

Nota: Si deseas utilizar la API de MapQuest, la API requiere una clave. Busca en Internet la URL para obtener una clave MapQuest. Utiliza los parámetros de búsqueda: developer.mapquest. También puedes buscar en Internet la URL actual que describe la política de privacidad de MapQuest.

6. Aplicaciones de API RESTful

Muchos sitios web y aplicaciones utilizan API para acceder a la información y prestar servicio a sus clientes. Por ejemplo, cuando se utiliza un sitio web de servicios de viajes, el servicio de viajes utiliza la API de varias aerolíneas para proporcionar al usuario información sobre la aerolínea, el hotel y otros datos.

Algunas solicitudes de API de RESTful pueden realizarse escribiendo en la URI desde un navegador web. La API de direcciones de MapQuest es un ejemplo de ello. Una solicitud de RESTful API también puede realizarse de otras maneras.

Haz clic en cada escenario de aplicación de la API a continuación para obtener más información.

Los desarrolladores a menudo mantienen sitios web que incluyen información sobre la API, información de parámetros y ejemplos de uso. Estos sitios también pueden permitir al usuario realizar la solicitud de API dentro de la página web del desarrollador introduciendo los parámetros y otra información. En la siguiente ilustración se muestra un ejemplo de la página web de la API direcciones (Directions) de MapQuest.

MapQuest Directions API
MapQuest Directions API

Postman es una aplicación para probar y usar las API de REST. Está disponible como una aplicación para el navegador o como una instalación independiente. Contiene todo lo necesario para construir y enviar solicitudes de API REST, incluyendo la introducción de parámetros y claves de consulta. Postman te permite recopilar y guardar las llamadas a las API que se utilizan con frecuencia en el historial, o como colecciones. Postman es una excelente herramienta para aprender a construir solicitudes de API, y para analizar los datos que se devuelven de una API. La siguiente figura muestra un ejemplo de uso de la API de MapQuest con Postman.

Postman
Postman

También se puede llamar a las API desde un programa Python. Esto permite una posible automatización, personalización e integración de aplicaciones de la API. En la siguiente ilustración se muestra un ejemplo de parte de un programa Python utilizado para enviar solicitudes a la API de MapQuest.

API con Python
API con Python

Mediante el uso de protocolos como NETCONF (NET CONFiguration) y RESTCONF, los sistemas operativos de red están empezando a proporcionar un método alternativo de configuración, supervisión y gestión. Por ejemplo, la siguiente salida podría ser la respuesta de apertura de un router después de que el usuario haya establecido una sesión de NETCONF en la línea de comandos. Sin embargo, trabajar en la línea de comandos no es automatizar la red. En su lugar, un administrador de red puede utilizar scripts Python u otras herramientas de automatización, como Cisco DNA Center, para interactuar programáticamente con el router.

$ ssh admin@192.168.0.1 -p 830 -s netconf
admin@192.168.0.1's password:
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<capabilities>
  <capability>urn:ietf:params:netconf:base:1.1</capability>
  <capability>urn:ietf:params:netconf:capability:candidate:1.0</capability>
  <capability>urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring</capability>
  <capability>urn:ietf:params:xml:ns:yang:ietf-interfaces</capability>
  [output omitted and edited for clarity]
</capabilities>
<session-id>19150</session-id></hello>

Glosario: Si tienes dudas con algún término especial, puedes consultar este diccionario de redes informáticas.

¡Listo! Sigue visitando nuestro blog de curso de redes, dale Me Gusta a nuestra fanpage; y encontrarás más herramientas y conceptos que te convertirán en todo un profesional de redes.

Application Programming Interface CCNA
Siguiente
API
El Mejor Pack de CCNA[Clic Aquí]