Search API has a versatile search engine solution designed to seamlessly connect with any NonSQL engine. It offers a unified interface for interacting with different search engines, allowing you to utilize the same code for every request. The Search API achieves this through its implementation-defined integration with specific search engines while maintaining consistency in its usage.
Key Features
Search Engine Agnosticism: The Search API is designed to be independent of any particular search engine. It provides a flexible and adaptable solution that can seamlessly integrate with various NonSQL engines.
Universal Code Usage: With the Search API, you can utilize the same code for all search engine requests. Regardless of the underlying search engine implementation, the API provides a consistent interface to interact with.
Normalization of Parameters and Responses: The Search API incorporates a normalization process for parameters and responses. This normalization ensures that requests and results are interpreted uniformly across different search engine implementations.
Implementation-Specific Integration: Each specific search engine implementation is responsible for interpreting and executing the normalized parameters and responses. The Search API facilitates this integration by providing a standardized interface, allowing for efficient communication between the API and the search engine.
The connection manager is in charge of the loading of the connection configurations and the initialization with every engine specific implementation. It is also in charge to open and close the connection, pool size, throttling, node balancing,...
You can get the connection Manager in your code using:
from app.rest import connection_manager
The default connection is the engine connection with the explicit default flag in true, or if none with the flag, the first in the list of connections. This connection is used as well for all internal transactions of Search API such as logging, feedback, analytics,...
To get the default connection, just use the code line below:
self.engine_conn = connection_manager.get_default()
You can have multiple connections to the same or different types of NonSQL engines, all with a name you can refer to, in order to get said connection.
To get a connection by name, just use the code line below:
self.engine = connection_manager.get_engine(name=engine_name)
All engine connections have the generic connection focus on managing the specific aspects of the REST connection.
Property | Description | Default | Type | Required |
---|---|---|---|---|
name | Specify the name of this engine | string (pattern: "[a-zA-Z\d_-]+") | Yes | |
type | Type of the engine to use for searches | string (enum: "elasticsearch", "opensearch") | Yes | |
default | If more than one, default = True indicates which engines will be used for Search API storage | false | boolean | No |
engine_url | URLs to the engine nodes | string or array of strings (minLength: 1, maxLength: 65536, format: uri) | Yes | |
index_prefix | Prefix for all search API indexes | "sa" | string (pattern: "[a-zA-Z\d_]+") | No |
pool_connections | The number of connection pools to cache | 10 | integer | No |
pool_maxsize | The maximum number of connections to save in the pool. | 100 | integer | No |
pool_block | Whether the connection pool should block for connections. | false | boolean | No |
headers | Dictionary with the predefined headers, express has header name (key), and its value | {} | object | No |
proxies | {} | object | No | |
params | Dictionary with the predefined parameters, express has parameter name (key), and its value | {} | object | No |
auth | object | No | ||
verify | Defaults to True , requiring requests to verify the TLS certificate at the remote end. | true | boolean | No |
cookies | Dictionary with the predefined cookies, express has cookie name (key), and its value | {} | object | No |
cert | string or array or string or file-path | No | ||
max_redirects | Maximum times the request is allowed to be redirected. | 30 | integer (minimum: 1) | No |
max_retries | Number of times the server will retry a failed request before throwing an error. | 10 | integer (minimum: 0) | No |
retry_backoff_factor | A backoff factor to apply between attempts after the second try. The connection will sleep for {backoff factor} * (2 ** ({number of total retries} - 1)) seconds. If the backoff_factor is 0.1, then will sleep for [0.0s, 0.2s, 0.4s, ...] between retries | 2.5 | number (minimum: 0) | No |
retry_on_timeout | Should timeout trigger a retry on a different node? | false | boolean | No |
timeout | Maximum time the server will wait for a request to be answered. | 30 | integer (minimum: 1) | No |
allow_redirects | Allow the request to be redirected | true | boolean | No |
trust_env | Trust environment settings for proxy configuration, default authentication, and similar. | true | boolean | No |
use_throttling | Limit the number of API requests the server can make in a certain period. | false | boolean | No |
throttling_rate | Number of simultaneous calls allowed per minute | 5000 | integer (minimum: 100) | No |
throttling_connection_rate | 50 | integer (minimum: 1) | No | |
randomize_nodes_in_pool | Set to false to not randomize nodes within the pool. | true | boolean | No |
node_selector_class | Class to be used to select nodes within the NodePool | "round_robin" | string (enum: "round_robin", "random") | No |
dead_node_backoff_factor | Exponential backoff factor to calculate the amount of time to timeout a node after an unsuccessful API call | number | No | |
max_dead_node_backoff | Maximum amount of time to timeout a node after an unsuccessful API call | number | No | |
log_requests | If True, every request done by the engine will be logged | false | boolean | No |