Version v15 (and Later)
Learn How to Install, Initialize and Create Classes for Version 15 of the SDK
Last updated
Learn How to Install, Initialize and Create Classes for Version 15 of the SDK
Last updated
The basic concepts of the SDK are documented on the root page, linked below (this is because they are the same for all versions of this package):
This document focuses on the initialization of the SDK and how to use the concrete client classes.
The SDK is available on nuget.org. You can install it with:
The main entry class is ISquidexClient
which handles authentication and creates the actual client classes, where each client is used for one endpoint such as assets, schemas and so on.
The client creates an access token using the client credentials and caches this token in the memory for 30 days. When the token expires, it is recreated automatically. The cache is not shared between the instances of your application and it is not needed.
Read more about the authentication flow and best practices below:
To instantiate the client you need the App Name, the Client Id and Client Secret. For self-hosted installations the URL is also required. For Squidex Cloud it is https://cloud.squidex.io
.
The client no longer supports multiple Apps anymore. Use one client per App.
If you use Dependency Injection (especially in ASP.NET Core) you can use the following package:
This package provides extension methods to register the Squidex Client at the service collection.
You can inject ISquidexClient
to your other classes.
The configuration uses the Options Pattern, so it can also be configured in the following way:
Another option is to bind it to a configuration section as follows:
Multiple Apps can be managed with the service provider by using named registrations as shown in the snippet below:
Inject the ISquidexClientProvider
instance to resolve a concrete client.
The package also integrates the HttpClientFactory to implement resilient HTTP requests. For example, this can be used to enable logging or to integrate Polly, a resilience and transient-fault-handling library.
You can implement changes to the HTTP pipeline using the following method:
The classes for concrete endpoints are properties of the client class. These instances are cached and a single instance is shared between all calls. Therefore, storing the instance in a separate variable is not required.
The content clients are also cached and can be resolved with the following method:
The content clients are cached internally using a thread safe dictionary.
The endpoint clients are not registered in the service locator. You have to register them manually if needed. It is best to use the root client class, especially if you work with multiple Apps. For performance reasons, this is not required.