The API Server stores data securely encrypted on the client and in the database.
The certificate is configured when the API server is installed on the IIS.
For more information about configuring encryption, see the One Identity Manager Web Application Configuration Guide.
Because the API Server is stateless, save the API methods without a client specific state.
For example, you cannot, therefore, define global variables or store session object status data. When the API Server processes are restarted, these values are not restored.
Access to current HTTP requirements over ASP.NET APIs is not supported.
After enabling routes, you cannot change the definition objects anymore.
Use asynchronous code for defining API methods. This supports more efficient usage of server resources and improves performance of the system under load. The methods of the API and the underlying object model convert this asynchronousity using the Task-based Asynchronous Pattern (TAP). For more information about TAP, see https://docs.microsoft.com/de-de/dotnet/standard/asynchronous-programming-patterns/task-based-asynchronous-pattern-tap.
Do not use the HttpContext.Current method when you define API methods. You can query the current HTTP requirements with the QBM.CompositionApi.ApiManager.Context.Current static method.
If you define API methods that modify data, do NOT use the GET method.
In this chapter, you will find general policies and conventions, which you must take into account when you create an API.
In this section, you will find information about handling queries that are sent to the API Server.
When a query is sent to the API Server, there is a test to ascertain the success of the primary and, possibly, secondary login in the session for the current project (see Authentication).
NOTE: This test is not done if the API method used by the query is marked as AllowUnauthenticated.
The imx-session-<API project name> cookie is evaluated to allocate the current session.
If a cookie is passed that cannot be associated with an active session in the current process, the security token in the cookie is used to set up a new session (see Session status and security tokens).
If there is no primary login, the API Server tries to establish a database connection through one of the enabled single sign-on authentication modules.
If login cannot be carried out, the process is canceled and the HTTP error code 500 is passed to the client (see Response codes).
The API Server checks whether the currently logged in user is authorized to run the method. If the user does not have the required permissions, the process is canceled and the HTTP error code 500 is passed to the client (see Response codes).
The API Server calls the validators stored with the API method one by one. If one fails, the process is canceled and the HTTP error code 400 is passed to the client (see Response codes).
Determines the WHERE clause with internal and external filters
Loads data from the database
Enriches entities with calculated columns
Entities in delayed logic mode can be changed with a POST query or deleted with a DELETE query. Entities in this mode are stateless and do not occupy resources on the server after the query has been processed.
Supported HTTP methods:
GET (for loading entities)
POST (for changing entities)
DELETE (for deleting entities)
Interactive entities must be created once with a PUT query and after that they obtain their own ID. Use the ID in subsequent queries (POST or DELETE).
Supported HTTP methods:
PUT (for creating interactive entities)
POST (for changing interactive entities)
DELETE (for deleting interactive entities)
© ALL RIGHTS RESERVED. Terms of Use Privacy Cookie Preference Center
