WARNING: Version 5.x has passed its EOL date.
This documentation is no longer being maintained and may be removed. If you are running this version, we strongly advise you to upgrade. For the latest information, see the current release documentation.
Transports
editTransports
editThe ITransport
interface can be seen as the motor block of the client. Its interface is
deceitfully simple, yet it’s ultimately responsible for translating a client call to a response.
If for some reason you do not agree with the way we wrote the internals of the client,
by implementing a custom ITransport
, you can circumvent all of it and introduce your own.
Transport is generically typed to a type that implements IConnectionConfigurationValues
This is the minimum ITransport
needs to report back for the client to function.
In the low level client, ElasticLowLevelClient
, a Transport
is instantiated like this:
var lowLevelTransport = new Transport<ConnectionConfiguration>(new ConnectionConfiguration());
and in the high level client, ElasticClient
, like this
var highlevelTransport = new Transport<ConnectionSettings>(new ConnectionSettings()); var connectionPool = new SingleNodeConnectionPool(new Uri("http://localhost:9200")); var inMemoryTransport = new Transport<ConnectionSettings>( new ConnectionSettings(connectionPool, new InMemoryConnection()));
The only two methods on ITransport
are Request()
and RequestAsync()
; the default ITransport
implementation is responsible for introducing
many of the building blocks in the client. If you feel that the defaults do not work for you then you can swap them out for your own
custom ITransport
implementation and if you do, please let us know as we’d love to learn why you’ve go down this route!
var response = inMemoryTransport.Request<SearchResponse<Project>>( HttpMethod.GET, "/_search", new { query = new { match_all = new { } } }); response = await inMemoryTransport.RequestAsync<SearchResponse<Project>>( HttpMethod.GET, "/_search", new { query = new { match_all = new { } } });