For the complete documentation index, see llms.txt. This page is also available as Markdown.

Endpoint

Gli endpoint sono definiti dal loro URI e dal metodo HTTP. Le chiamate effettuate al server Universal che corrispondono all'endpoint API e al metodo definiti eseguono lo script dell'endpoint API.

New-PSUEndpoint -Url '/endpoint' -Method 'GET' -Endpoint {
   "Hello, world!"
}

Per invocare il metodo sopra, può usare Invoke-RestMethod.

Invoke-RestMethod http://localhost:5000/endpoint

Quando definisce gli endpoint nell'API di gestione, può saltare la chiamata New-PSUEndpoint, poiché la console di amministrazione la definisce.

Proprietà API

L'unico contenuto che deve fornire nell'editor è lo script che desidera chiamare.

Contenuto API

Metodi HTTP

Gli endpoint possono avere uno o più metodi HTTP definiti. Per determinare quale metodo è usato da un endpoint, usi la variabile integrata $Method.

URL variabile

Gli URL possono contenere segmenti variabili. Può indicare un segmento variabile usando i due punti (:). Ad esempio, il seguente URL fornirebbe una variabile per l'ID dell'utente. La variabile $Id sarà definita all'interno dell'endpoint quando viene eseguito. Le variabili devono essere univoche nello stesso URL dell'endpoint.

Per chiamare questa API e specificare l'ID, proceda come segue:

Parametri della stringa di query

I parametri della stringa di query vengono passati automaticamente agli endpoint come variabili a cui può poi accedere. Ad esempio, se ha un endpoint che si aspetta una variabile $Id, può fornirla nella stringa di query.

La chiamata Invoke-RestMethod risultante deve quindi includere il parametro della stringa di query.

Quando usa più parametri della stringa di query, si assicuri che l'URL sia racchiuso tra virgolette in modo che PowerShell lo interpreti correttamente. Includere una e commerciale (&) senza virgolette causerà problemi sia in Windows PowerShell sia in PowerShell 7.

Considerazioni sulla sicurezza

Quando accetta input tramite parametri della stringa di query, potrebbe essere vulnerabile a CWE-914: Improper Control of Dynamically-Identified Variables. Consideri di usare un blocco param per garantire che vengano forniti all'endpoint solo parametri validi.

Di seguito è riportato un esempio di CWE-914. Includa un parametro della stringa di query $IsChallengePassed per bypassare la challenge.

Per evitare questo particolare problema, può usare un blocco param.

Gli header della richiesta sono disponibili nelle API tramite la variabile $Headers. La variabile è una hashtable. Per accedere a un header, usi la seguente sintassi:

I cookie della richiesta sono disponibili nelle API tramite la variabile $Cookies. La variabile è una hashtable. Per accedere a un cookie, usi la seguente sintassi:

Rimandi indietro i cookie della richiesta con il cmdlet New-PSUApiResponse. Usi il parametro -Cookies con una hashtable fornita.

Corpo

Per accedere al corpo di una richiesta, dovrà semplicemente accedere alla variabile $Body. La variabile $Body di Universal sarà una stringa. Se si aspetta JSON, dovrebbe usare ConvertFrom-Json.

Per chiamare l'endpoint sopra, specifichi il corpo di Invoke-RestMethod.

Log in tempo reale

Può visualizzare le informazioni del log in tempo reale per qualsiasi endpoint facendo clic sulla scheda del log. I log in tempo reale includono URL, metodo HTTP, indirizzo IP di origine, stream PowerShell, codice di stato, Content Type restituito e lunghezza del contenuto HTTP.

Può scrivere nel log in tempo reale dall'interno dei suoi endpoint con cmdlet come Write-Host.

Log in tempo reale dell'endpoint

Test

Può usare la scheda Test nell'editor degli endpoint per testare le sue API. Usando questo strumento di test, può modificare gli header, la stringa di query e il corpo. Può anche modificare l'autenticazione e l'autorizzazione per il test.

Scheda Test dell'endpoint

Quando usa la scheda Test, qualsiasi modifica ai valori del test comporterà un blocco di codice aggiornato che potrà poi usare in PowerShell. Faccia clic sulla scheda Code per visualizzare il codice del test.

Inoltre, i test eseguiti nel tester saranno archiviati per 30 giorni per consentire di ripetere il test senza dover riconfigurare tutte le proprietà. Facendo clic sul pulsante Apply si configurerà lo strumento di test con le stesse proprietà.

Cronologia dei test

Dati del form

Può passare dati a un endpoint come dati del form. I dati del form verranno passati al suo endpoint come parametri.

Può quindi usare una hashtable con Invoke-RestMethod per passare i dati del form.

Dati JSON

Può passare dati JSON a un endpoint e verranno associati automaticamente a un blocco param.

Può quindi inviare dati JSON all'endpoint.

Blocco param

Può usare un blocco param all'interno del suo script per imporre parametri obbligatori e fornire valori predefiniti per i parametri facoltativi come i parametri della stringa di query. Variabili come $Body, $Headers e $User vengono fornite automaticamente.

Nell'esempio seguente, il parametro $Name è obbligatorio e il parametro $Role ha un valore predefinito di Default.

Quando usa il blocco param con parametri di route come nell'esempio sopra, deve includere la variabile di route nel suo parametro. Se non è specificata, non avrà accesso a quel valore.

Ad esempio, la seguente variabile $Name è sempre $null. L'endpoint restituisce sempre false.

Se usa l'attributo CmdletBinding o Parameter all'interno del blocco param, l'endpoint imporrà rigorosamente quali parametri sono consentiti nell'endpoint.

Ad esempio, quanto segue impone che il parametro name sia specificato.

Detto questo, non può specificare parametri aggiuntivi all'endpoint. Fare quanto segue causerà un errore.

Se modifica il suo endpoint per evitare di usare l'attributo Parameter, può passare un numero qualsiasi di parametri e saranno associati come variabili e non come parametri dell'endpoint.

Set di parametri dei metodi

Può definire set di parametri usando i parametri dei metodi. Per impostazione predefinita, PowerShell Universal ispezionerà il blocco param per determinare se sono specificati i nomi di metodo HTTP Get, Put, Post, Delete o altri e li includerà automaticamente. Quando gli endpoint accettano più metodi, potrebbe non essere in grado di determinare quale set di parametri chiamare in base ai dati forniti. Nell'esempio seguente, sia Get sia Post accettano il parametro name. Inoltre non c'è modo di chiamare Post senza un nome, quindi la convalida potrebbe fallire.

Per ovviare a questo, includa i parametri Post e Get che fanno parte dei rispettivi set di parametri. PowerShell Universal includerà questo parametro per garantire che venga chiamato il set di parametri corretto.

Restituzione dei dati

Si presume che i dati restituiti dagli endpoint siano dati JSON. Se restituisce un oggetto dallo script block dell'endpoint, viene automaticamente serializzato in JSON. Se desidera restituire un altro tipo di dati, può restituire una stringa formattata come preferisce.

Elaborazione dei file

Caricamento dei file

Può elaborare i file caricati usando il parametro $Data per accedere all'array di byte dei dati caricati nell'endpoint.

Può anche salvare il file in una directory.

Download dei file

Può inviare i file usando il cmdlet New-PSUApiResponse.

Restituire risposte personalizzate

Può restituire risposte personalizzate dagli endpoint usando il cmdlet New-PSUApiResponse nel suo endpoint. Questo cmdlet le consente di impostare il codice di stato, il content type e persino di specificare i dati byte[] per il contenuto da restituire.

Può anche restituire dati del corpo personalizzati con il parametro -Body di New-PSUApiResponse.

L'invocazione del metodo REST restituisce il codice di errore personalizzato.

Può controllare il content type dei dati restituiti con il parametro -ContentType.

Può controllare gli header della risposta con una hashtable di valori che passa al parametro -Headers.

Runspace persistenti

I runspace persistenti le consentono di mantenere lo stato del runspace tra le chiamate API. Questo è importante per gli utenti che eseguono un qualche tipo di inizializzazione all'interno dei loro endpoint che non desiderano eseguire nelle chiamate API successive.

Per impostazione predefinita, i runspace vengono reimpostati dopo ogni esecuzione. Ciò rimuove variabili, moduli e funzioni definiti durante l'esecuzione dell'API.

Per abilitare i runspace persistenti, dovrà configurare un ambiente per la sua API. Imposti il parametro -PersistentRunspace per abilitare questa funzionalità. Questo viene configurato nello script environments.ps1.

Può quindi assegnare l'ambiente API nello script settings.ps1.

Timeout

Per impostazione predefinita, gli endpoint non andranno in timeout. Per impostare un timeout per i suoi endpoint, può usare il parametro -Timeout di New-PSUEndpoint. Il timeout è impostato in numero di secondi.

Contenuto dell'endpoint esterno

Può definire il percorso di un file di contenuto dell'endpoint esterno con il parametro -Path di New-PSUEndpoint. Il percorso è relativo alla directory .universal nel Repository.

Il contenuto del file endpoints.ps1 è quindi il seguente:

API C#

Le API C# sono abilitate come plugin.

Non esiste un'interfaccia utente per creare un'API C#, quindi deve farlo usando i file di configurazione. Innanzitutto, crei un file .cs che esegue la sua API.

Avrà accesso a un parametro request che include tutti i dati sulla richiesta API.

Avrà anche accesso a una proprietà ServiceProvider che le consente di accedere ai servizi all'interno di PowerShell Universal. Attualmente non sono ben documentati, ma di seguito è riportato un esempio di riavvio di una dashboard.

Alcuni altri servizi utili includono:

  • IDatabase

  • IApiService

  • IConfigurationService

  • IJobService

Può scegliere di restituire un ApiResponse dal suo endpoint.

Una volta definito il file dell'endpoint C#, può aggiungerlo modificando endpoints.ps1.

Il servizio PowerShell Universal compila ed esegue automaticamente gli endpoint C#.

API

Vedi anche

Ultimo aggiornamento

È stato utile?