Skip to main content

Sesión 8 - Plataformas IoT

Objetivos
  • Comprender los conceptos basicos de Rest para interactuar con plataformas IoT
  • Diseñar una aplicación basica Rest
  • En construcción....

Conceptos vistos​

Hasta el momento hemos visto los siguientes temas:

  • Conceptos basicos de programación de las sistemas de desarrollo Arduino UNO y ESP32.
  • Algunos conceptos basicos entre sensores y actuadores.
  • Comunicación serial.
  • Comunicación inalambrica usando Wifi.

De los temas anteriormente vistos, es importante resaltar la importancia que juega la comunicación en una arquitectura IoT; asi mismo, que estas no son las unicas maneras de trabajar con datos, sin embargo, con saber por ahora esto basta.

De los temas anteriormente vistos, es importante resaltar la importancia que juega la comunicación en una arquitectura IoT; asi mismo, que estas no son las unicas maneras de trabajar con datos, sin embargo, con saber por ahora esto basta.

Tal y como se muestra en la siguiente figura (tomada de IoT Engineering - link)

Iot-reference-model

En el modelo de referencia IoT, uno de los elementos claves son las plataformas IoT pues permiten almacenar y almacenar (entre otras cosas) datos de sensores. Para conectar las cosas con estas plataformas con las cosas, es importante conocer la forma como se lleva a cabo la comunicación y la interación establecida por estas la cual, generalmente es a traves de peticiones HTTP expuestas a traves de APIs.

Respecto al manejo de APIs, el siguiente documento se muestra un ejemplo tipico de un API (cheatsheet_api)

APIs​

Una interfaz de programación de aplicaciones (API) permite una conversación de software con otra. Utiliza interacciones basadas en la web o protocolos de comunicación comunes y sus propios estándares patentados determinando qué tipo de datos, servicios y funcionalidad expone la aplicación a terceros.

API

Las API están diseñadas para ser consumidas mediante programación por otras aplicaciones y también pueden ser usadas por usuarios que desean interactuar con la aplicación manualmente.

Los tres tipos más populares de estilos arquitectónicos API son:

  • RPC
  • SOAP
  • REST

API REST​

Transferencia de Estado Representacional (REST) es un estilo arquitectónico escrito por Roy Thomas Fielding.

Una API de servicio web REST (API REST) es una interfaz de programación que se comunica a través de HTTP, por lo que utiliza los mismos conceptos que el protocolo HTTP:

  • Solicitudes/respuestas HTTP
  • Verbos HTTP
  • Código de estado HTTP
  • Encabezados/cuerpo HTTP

api-rest

A continuación vamos a analizar tanto las solicitudes como las respuestas.

Solicitudes de API REST​

Las solicitudes de API REST son solicitudes HTTP en las que una aplicación (cliente) pide al servidor que realice una función. Las solicitudes de API REST se componen de cuatro componentes principales:

  • Identificador uniforme de recursos (URI): También conocido como localizador uniforme de recursos (URL), identifica qué recurso desea manipular el cliente.

    componentes-uri

    Tal y como se resalta en la figura anterior, las URI tienen los siguientes componentes:

    • Esquema: especifica qué protocolo HTTP se debe usar, http o https.
    • Autoridad: consta de dos partes, a saber, host y puerto
    • Ruta de acceso: representa la ubicación del recurso, los datos u objeto, que se va a manipular en el servidor.
    • Consulta: proporciona detalles adicionales sobre el ámbito, el filtrado o para aclarar una solicitud.

  • Método HTTP:: Empleado para comunicarse con los servicios web para los que se solicita la acción para el recurso dado. La asignación sugerida del método HTTP a la acción es la siguiente:

    Método HTTP:AcciónDescripción
    POSTCrear (Create)Crear un nuevo objeto o recurso.
    GETlectura (Read)Recuperar detalles de recursos del sistema.
    PUTActualizarReemplace o actualice un recurso existente.
    PARCHEActualización parcialActualice algunos detalles de un recurso existente.
    DELETEEliminar (Delete)Remover un recurso del sistema.

  • Encabezado: tienen el formato de pares nombre-valor separados por dos puntos (:); esto es, [nombre]: [valor]. Podemos distinguir dos tipos de encabezados:

    • Encabezados de solicitud: incluye información adicional que no esté relacionada con el contenido del mensaje.

      ClaveValor de ejemploDescripción
      AutorizaciónDMFNCMFUDDP2YWDYYW básicoProporciona credenciales para autorizar la solicitud

    • Encabezados de entidad: información adicional que describe el contenido del cuerpo del mensaje.

      ClaveValor de ejemploDescripción
      Tipo de contenidoaplicación/ JSONPEspecificar el formato de los datos en el cuerpo

  • Cuerpo: El cuerpo de la solicitud de API REST contiene los datos correspondientes al recurso que el cliente desee manipular. Las solicitudes de API REST que utilizan el método HTTP POST, PUT y PATCH suelen incluir un cuerpo lo que hace que cuerpo sea opcional dependiendo del método HTTP.

Respuestas API REST​

Las respuestas de la API REST son respuestas HTTP que comunica los resultados de la solicitud HTTP de un cliente. La Respuesta REST API se componen de tres componentes principales:

  • Estado HTTP: El código de estado HTTP ayuda al cliente a determinar el motivo del error y a veces puede proporcionar sugerencias para solucionar el problema. Los códigos de estado HTTP constan de tres dígitos, donde el primer dígito es la categoría de respuesta y los otros dos dígitos son asignados en orden numérico. Hay cinco categorías diferentes de códigos de estado HTTP:

    • 1xx - Informativo: con fines informativos, las respuestas no contienen un cuerpo
    • 2xx - Éxito: el servidor recibió y ha aceptado la solicitud
    • 3xx - Redirección: el cliente tiene que tomar una acción adicional para completar la solicitud
    • 4xx - Error de cliente: la solicitud contiene un error como sintáxis incorrecta o entrada no válida
    • 5xx - Error del servidor: no se pueden cumplir las solicitudes válidas.

    Los codigos de estado mas comunes se muestran a continuación:

    Código de Estado HTTPMensaje de estadoDescripción
    200AceptarLa solicitud se realizó correctamente y normalmente contiene una carga útil (cuerpo)
    201CreadaSe cumplió la solicitud y se creó el recurso que fue solicitado
    202AceptadaLa solicitud ha sido aceptada para su procesamiento y está en proceso
    400Solicitud no validaLa solicitud no se procesará debido a un error con la solicitud
    401No autorizadoLa solicitud no tiene credenciales de autenticación válidas para realizar la solicitud
    403ProhibidaLa solicitud ha sido entendida pero ha sido rechazada por el servidor
    404No se encontróNo se puede cumplir la solicitud porque la ruta de acceso del recurso de la solicitud no se encontró en el servidor
    500Error del servidor internoNo se puede cumplir la solicitud debido a un error del servidor
    503El servicio no está disponibleNo se puede cumplir la solicitud porque actualmente el servidor no puede manejar la solicitud

  • Encabezado: El encabezado de la respuesta proporciona información adicional entre el servidor y el cliente en el formato de par nombre-valor que está separado por dos puntos (:), [nombre]:[valor]. Hay dos tipos de encabezados:

    • Encabezados de respuesta: contiene información adicional que no está relacionada con el contenido del mensaje. Los encabezados de respuesta típicos para una solicitud de API REST incluyen:

      ClaveValor de ejemploDescripción
      Set-CookieJSESSIONID=30A9DN810FQ428P; Ruta=/Se utiliza para enviar Cookies desde el servidor
      Control de cachéControl de caché: max-edad=3600, públicoEspecificar directivas que DEBEN ser obedecidas por todos los mecanismos de almacenamiento en el caché

    • Encabezados de entidad: son información adicional que describe el contenido del cuerpo del mensaje. Un encabezado de entidad común especifica el tipo de datos que son devueltos:

      ClaveValor de ejemploDescripción
      Tipo de contenidoAplicación/JSONSEspecificar el formato de los datos en el cuerpo

  • Cuerpo: Contiene los datos asociados a la respuesta.

Algunos APIs de utilidad​

Referencias​