HTTP

Referencia del driver HTTP: sondear puntos de conexión HTTP y HTTPS como tags, las credenciales, el mapeo de rutas, la interpretación del cuerpo, las escrituras PUT y los tipos.

Ver como Markdown

El driver HTTP sondea puntos de conexión HTTP genéricos como tags: un sensor de red local con un servidor web diminuto, una puerta de enlace que publica lecturas en URL fijas, un servicio propio. Es el driver en modo cliente más simple del producto: Ganter Lab se conecta al equipo con peticiones GET simples y lee el cuerpo de cada respuesta como un solo valor.

Dos propiedades trazan la raya alrededor de para qué sirve:

El transporte es el que dice la dirección. Un dispositivo cuyo host está escrito https://host llega a su servicio sobre TLS; un host escrito solito es HTTP sin cifrar. De cualquiera de las dos maneras, el driver manda la credencial del dispositivo en cada petición, un nombre de usuario con su contraseña como HTTP Basic o un token de portador. Lo que los drivers AVEVA PI y Redfish todavía ponen para esos dos servicios es su vocabulario: rutas PI y WebId, árboles de recursos de Redfish, que este driver no conoce.
El cuerpo entero de la respuesta es el valor. El driver no es un extractor de campos JSON: un tag numérico espera que el cuerpo sea el número pelón.

Los campos de conexión

Campo	Qué es	Formato	Valor inicial
Host o IP	El nombre de host o la dirección IP del punto de conexión. Escrito `https://host` se llega a él sobre TLS, que es lo que deja una credencial fuera del cable; un host solito es HTTP sin cifrar.	Nombre de host, IP, o cualquiera de los dos con `http://` o `https://` enfrente	vacío
Puerto	El puerto TCP. Cero significa el puerto en el que contesta el transporte: 80 sin cifrar, 443 sobre HTTPS.	número de puerto	0
Ruta del recurso	Un prefijo de ruta opcional que se pone delante de la ruta de todos los tags, por ejemplo `api/v2`. En blanco no prefija nada.	texto de ruta	en blanco
Nombre de usuario	La cuenta para la autenticación HTTP Basic, usada solo cuando no hay ningún token de portador puesto. Vacío (y sin token) deja las peticiones anónimas.	Texto libre	vacío
Contraseña	La contraseña que va con el nombre de usuario. Protegida en reposo por usuario de Windows; un secreto capturado en otra cuenta de Windows se muestra como ilegible y hay que volver a ingresarlo.	Texto libre	vacía
Token de portador	Un token que se envía como `Authorization: Bearer …` en cada petición. Cuando está puesto, gana sobre el par de nombre de usuario y contraseña. Se protege en reposo de la misma manera.	Texto del token	vacío

Al conectarse, el driver verifica el punto de conexión con una petición HEAD a la dirección configurada, host más ruta del recurso, y cae en GET cuando HEAD no está implementado; una dirección que conteste bien a cualquiera de las dos cuenta como alcanzable. Por eso un servicio cuya raíz contesta 404 mientras su API contesta con normalidad está en línea, siempre que la ruta del recurso apunte a la API. Sobre HTTPS, el certificado TLS del servicio tiene que pasar la validación normal de certificados de Windows. Una credencial en una dirección que no nombra ningún TLS viaja sin cifrar, y la estación lo dice en el diario del conector cuando el dispositivo se conecta. Cada petición tiene diez segundos: un punto de conexión que acepta la conexión y después se queda callado cuesta una lectura, no el dispositivo entero, porque los demás tags del dispositivo se leen en la misma pasada. El intervalo de sondeo es configurable: el valor predeterminado del dispositivo (1000 ms) vale para todo tag que no declare el suyo.

El direccionamiento del tag

El campo Ruta del tag es la ruta de la URL relativa a la ruta del recurso del dispositivo:

Campo	Qué hace	Valores	Valor inicial
Ruta	La ruta que se pide para este tag. La URL completa es `<transport>://<host>:<puerto>/<ruta del recurso>/<ruta>`.	Texto libre (obligatorio)	vacía

Ejemplo: con el host 192.168.0.40, la ruta del recurso api y la ruta de tag sensors/temp se sondea http://192.168.0.40/api/sensors/temp.

Las lecturas

Cada sondeo hace GET de la URL del tag e interpreta el cuerpo entero de la respuesta según el tipo de dato declarado del tag:

Tipo	Cuerpo aceptado
Float	Un número, en formato invariante (`21.5`, con punto decimal y sin separadores de miles)
Int32	Un entero (`42`)
Boolean	`true` o `false`
String	Cualquier cosa; el cuerpo es el valor tal cual (un documento JSON llega como su texto crudo)

Un cuerpo que el tipo declarado no puede interpretar, o un código de estado que no es de éxito, se lee como una lectura fallida: el tag pasa a mala calidad y su política de lectura fallida decide qué se presenta, como se describe en la página del Connector.

Las escrituras

Los tags con un modo de acceso escribible escriben con PUT a esa misma URL: el cuerpo es el valor en JSON, enviado con el tipo de contenido application/json. Un número va como un literal pelón (42.5), un booleano como true o false, y el texto va entre comillas ("automatic"). El punto de conexión decide qué hacer con él; un estado que no es de éxito se lee como una escritura fallida. Como en todos lados, la caja de escritura toma el valor de ingeniería y las etapas de conversión del tag se deshacen antes de que el valor bruto salga al bus, como se describe en la página del Connector.

Los tipos de dato admitidos

Boolean, Int32, Float y String.

Los comandos

Un tag lee un valor; un comando le pide al servicio que haga algo. Declare cada uno en el dispositivo, en la tarjeta Comandos de su página: un nombre, la ruta a la que se le hace POST (bajo la dirección propia del dispositivo, exactamente igual que la ruta de un tag) y, opcionalmente, el nombre del único valor que toma. El verbo Ejecutar de la fila lo envía y reporta qué contestó el servicio, y el comando se convierte además en un método del dispositivo dentro del espacio de direcciones OPC UA propio de esta estación, así que cualquier cosa que pueda llamar a un método puede lanzarlo. El valor que usted escriba se envía como el cuerpo de la petición, tal cual.

Lo que contesta el servicio es el resultado del comando. Un estado que el servicio devuelve fuera del rango de éxito es el servicio rechazando el comando, no la conexión fallando: el rechazo nombra el estado y cita lo que el servicio dijo con él ("HTTP 500: el quemador está bloqueado"), y nada más del dispositivo se perturba por eso.

El descubrimiento

El driver no tiene escaneo de descubrimiento. Agregue cada punto de conexión por su host y cada valor por su ruta; el flujo para agregar un dispositivo se describe en la página del Connector.