Endpoints
Endpoint configuration for Universal APIs.
Last updated
Endpoint configuration for Universal APIs.
Last updated
Copyright 2024 Ironman Software
Endpoints are defined by their URI and HTTP method. Calls made to the Universal server that match the API endpoint and method that you define will execute the API endpoint script.
To invoke the above method, you could use Invoke-RestMethod
.
When defining endpoints in the management API, you can skip the New-PSUEndpoint
call as it will be defined by the admin console.
The only contents that you need to provide in the editor will be the script you wish to call.
URLs can contain variable segments. You can denote a variable segment using a colon (:
). For example, the following URL would provide a variable for the ID of the user. The $Id
variable will be defined within the endpoint when it is executed. Variables must be unique in the same endpoint URL.
To call this API and specify the ID, you would do the following.
Query string parameters are automatically passed into endpoints as variables that you can then access. For example, if you had an endpoint that expected an $Id
variable, it could be provided via the query string.
The resulting Invoke-RestMethod
call must then include the query string parameter.
When accepting input via Query String parameters you may be vulnerable to CWE-914: Improper Control of Dynamically-Identified Variables. Consider using a param
block to ensure that only valid parameters are provided to the endpoint.
Below is an example of CWE-914. A $IsChallengePassed
query string parameter could be included to bypass the challenge.
In order to avoid this particular issue, you can use a param
block.
To access a request body, you will simply access the $Body
variable. Universal $Body
variable will be a string. If you expect JSON, you should use ConvertFrom-Json
.
To call the above endpoint, you would have to specify the body of Invoke-RestMethod
.
You can pass data to an endpoint as form data. Form data will be passed into your endpoint as parameters.
You can then use a hashtable with Invoke-RestMethod to pass form data.
PowerShell Universal 2.6 or later required.
You can pass JSON data to an endpoint and it will automatically bind to a param block.
You can then send JSON data to the endpoint.
You can use a param
block within your script to enforce mandatory parameters and provide default values for optional parameters such as query string parameters. Variables such as $Body
, $Headers
and $User
are provided automatically.
In the below example, the $Name
parameter is mandatory and the $Role
parameter has a default value of Default.
Data returned from endpoints will be assumed to be JSON data. If you return an object from the endpoint script block, it will be automatically serialized to JSON. If you want to return another type of data, you can return a string formatted however you chose.
You can process uploaded files by using the $Data
parameter to access the byte array of data uploaded to the endpoint.
You could also save the file into a directory.
You can send files down using the New-PSUApiResponse
cmdlet.
You can return custom responses from endpoints by using the New-PSUApiResponse
cmdlet in your endpoint. This cmdlet allows you to set the status code, content type and even specify the byte[] data for the content to be returned.
You can also return custom body data by using the -Body
parameter of New-PSUApiResponse
.
Invoking the REST method will return the custom error code.
You can control the content type of the data that is returned by using the -ContentType
parameter.
APIs that you create will automatically be added to the OpenAPI documentation that is generated by PowerShell Universal. You can access the Swagger documentation page by navigating to Security \ Tokens and clicking API Documentation. All your custom endpoints will be listed under APIs.
You can specify help text for your APIs using comment-based help. Including a synopsis, description and parameter descriptions will result in each of those pieces being documented in the OpenAPI documentation and Swagger age.
For example, with a simple /get/:id
endpoint, we could have comment-based help such as this.
The resulting Swagger page will show each of these descriptions.
Persistent runspaces allow you to maintain runspace state between API calls. This is important for users that perform some sort of initialization within their endpoints that they do not want to execute on subsequent API calls.
By default, runspaces will be reset after each execution. This will cause variables, modules and functions defined during the execution of the API to be removed.
To enable persistent runspaces, you will need to configure an environment for your API. Set the -PersistentRunspace
parameter to enable this feature. This is configured in the environments.ps1
script.
You can then assign the API environment in the settings.ps1
script.
Available in PowerShell Universal 2.8 or later.
By default, endpoints will not time out. To set a timeout for your endpoints, you can use the New-PSUEndpoint
-Timeout
parameter. The timeout is set in the number of seconds.
Available in PowerShell Universal 2.10 or later.
You can define the path to an external endpoint content file by using the -Path
parameter of New-PSUEndpoint
. The path is relative to the Repository directory. For example, the file layout would appear like this.
The content of the endpoints.ps1
file is then this.