HTTP

Riferimento del driver HTTP - interrogare endpoint HTTP e HTTPS come tag, credenziali, corrispondenza dei percorsi, analisi del corpo, scritture PUT e tipi.

Visualizza come Markdown

Il driver HTTP interroga endpoint HTTP generici come tag: un sensore di LAN con un minuscolo server web, un gateway che pubblica letture a URL fissi, un servizio scritto da te. È il driver in modo client più semplice del prodotto: è Ganter Lab a collegarsi all'apparecchiatura con semplici richieste GET, e legge il corpo di ogni risposta come un solo valore.

Due proprietà tracciano il confine di ciò a cui serve:

Il trasporto è quello che l'indirizzo dichiara. Un dispositivo il cui host è scritto https://host raggiunge il suo servizio in TLS; un host scritto da solo è HTTP in chiaro. In un modo o nell'altro il driver invia la credenziale del dispositivo a ogni richiesta, un nome utente e una password in HTTP Basic oppure un token di autorizzazione. Quello che i driver AVEVA PI e Redfish aggiungono ancora per quei due servizi è il loro lessico: percorsi PI e WebId, alberi di risorse di Redfish, di cui questo driver non sa nulla.
Il valore è tutto il corpo della risposta. Il driver non è un estrattore di campi JSON: un tag numerico si aspetta che il corpo sia il numero nudo.

Campi di connessione

Campo	Che cos'è	Formato	Predefinito
Indirizzo host	Il nome host o l'indirizzo IP dell'endpoint. Scritto `https://host` viene raggiunto in TLS, ed è questo che tiene una credenziale fuori dal cavo; un host da solo è HTTP in chiaro.	Nome host, IP, oppure uno dei due con `http://` o `https://` davanti	vuoto
Porta TCP	La porta TCP. Zero significa la porta su cui risponde il trasporto: 80 in chiaro, 443 in HTTPS.	numero di porta	0
Percorso della risorsa	Un prefisso di percorso facoltativo messo davanti al percorso di ogni tag, per esempio `api/v2`. Vuoto non aggiunge alcun prefisso.	testo di percorso	vuoto
Nome utente	L'account per l'autenticazione HTTP Basic, usato solo quando non è impostato alcun token di autorizzazione. Vuoto (e senza token) lascia le richieste anonime.	Testo libero	vuoto
Password del dispositivo	La password abbinata al nome utente. Protetta a riposo per utente di Windows; un segreto inserito sotto un altro account Windows si presenta come illeggibile e va reinserito.	Testo libero	vuoto
Token di autorizzazione	Un token inviato come `Authorization: Bearer …` a ogni richiesta. Quando è impostato vince sulla coppia nome utente e password. Protetto a riposo allo stesso modo.	Testo del token	vuoto

Alla connessione il driver verifica l'endpoint con una richiesta HEAD all'indirizzo configurato, host più percorso della risorsa, ripiegando su GET quando HEAD non è implementato; un indirizzo che risponde con successo a una delle due conta come raggiungibile. Un servizio la cui radice risponde 404 mentre la sua API risponde normalmente è quindi connesso, purché il percorso della risorsa punti all'API. In HTTPS il certificato TLS del servizio deve superare la normale convalida dei certificati di Windows. Una credenziale su un indirizzo che non dichiara TLS viaggia non cifrata, e la stazione lo scrive nel diario del connettore quando il dispositivo si collega. A ogni richiesta vengono concessi dieci secondi: un endpoint che accetta la connessione e poi non dice nulla costa una lettura, non l'intero dispositivo, perché gli altri tag del dispositivo vengono letti nella stessa passata. L'intervallo di interrogazione è configurabile: il valore predefinito del dispositivo (1000 ms) vale per ogni tag che non dichiari il proprio.

Indirizzamento dei tag

Il campo Percorso del tag è il percorso dell'URL relativo al percorso della risorsa del dispositivo:

Campo	Che cosa fa	Valori	Predefinito
Percorso	Il percorso richiesto per questo tag. L'URL completo è `<transport>://<host>:<port>/<resource path>/<path>`.	Testo libero (obbligatorio)	vuoto

Esempio: host 192.168.0.40, percorso della risorsa api, percorso del tag sensors/temp interroga http://192.168.0.40/api/sensors/temp.

Letture

Ogni interrogazione esegue una GET sull'URL del tag e analizza l'intero corpo della risposta secondo il tipo di dato dichiarato dal tag:

Tipo	Corpo accettato
Float	Un numero, in formato invariante (`21.5`, punto decimale, senza separatore delle migliaia)
Int32	Un intero (`42`)
Boolean	`true` oppure `false`
String	Qualunque cosa; il corpo è il valore tale e quale (un documento JSON arriva come il suo testo grezzo)

Un corpo che il tipo dichiarato non riesce ad analizzare, oppure un codice di stato diverso da un successo, si legge come lettura fallita: il tag passa a cattiva qualità e la sua politica di lettura fallita decide che cosa viene presentato, come è descritto nella pagina Connector.

Scritture

I tag con una modalità di accesso scrivibile scrivono con PUT sullo stesso URL: il corpo è il valore in JSON, inviato con tipo di contenuto application/json. Un numero va come letterale nudo (42.5), un booleano come true oppure false, e il testo va tra virgolette ("automatic"). È l'endpoint a decidere che cosa farne; uno stato diverso da un successo si legge come scrittura fallita. Come dappertutto, la casella di scrittura prende il valore ingegneristico e le fasi di conversione del tag vengono percorse all'indietro prima che il valore grezzo vada sul bus, come è descritto nella pagina Connector.

Tipi di dato supportati

Boolean, Int32, Float e String.

Comandi

Un tag legge un valore; un comando chiede al servizio di fare qualcosa. Dichiarane ciascuno sul dispositivo, nella scheda Comandi della sua pagina: un nome, il percorso a cui viene inviato con una POST (sotto l'indirizzo proprio del dispositivo, esattamente come il percorso di un tag) e, facoltativamente, il nome dell'unico valore che accetta. Il verbo Invia della riga lo manda e riferisce quello che il servizio ha risposto, e il comando diventa anche un metodo sul dispositivo nello spazio degli indirizzi OPC UA proprio di questa stazione, così qualunque cosa sappia chiamare un metodo lo può emettere. Il valore che scrivi viene inviato come corpo della richiesta, così come è scritto.

Quello che il servizio risponde è il risultato del comando. Uno stato che il servizio restituisce fuori dall'intervallo di successo è il servizio che rifiuta il comando, non la connessione che fallisce: il rifiuto nomina lo stato e cita quello che il servizio ha detto insieme a esso (« HTTP 500: il bruciatore è in blocco »), e nient'altro sul dispositivo ne viene disturbato.

Rilevamento

Il driver non ha alcuna scansione di rilevamento. Aggiungi ogni endpoint per host e ogni valore per il suo percorso; il flusso per aggiungere un dispositivo è descritto nella pagina Connector.