.NET clients - forward respsonse fast and lean when no error occurs

[knacktus]

Hi,

I'd like to achieve the following with as little overhead as possible:

1.  A web app calls an ASP.NET API.
2.  ASP.NET performs auth and adds some filter values according to the user's permissions.
3.  ASP.NET sends the request to ES.
4.  ASP.NET checks the response wether there was an error.
   a.  If no error occurs, the response should be forwarded as fast as possible. 
       No deserialization and re-serialization. 
       The fastest possible way - keep the response gzipped as send from ES.
   b.  If an error occurs, the error message should be logged.

I'm considering using either no client library - using plain http and JSON. But I like the advantages of connection pooling Elasticsearch.NET and NEST are providing.

I'd further opt for Elasticsearch.NET as I don't need and don't want to work with typed objects. But I'm stuck at how to handle the response for the use case described above.

Cheers,

Jan

[forloop (Russ Cam)]

It's possible to return a Stream from a request with Elasticsearch.Net, forgoing any deserialization of the response and thus allocation of a byte array, json string, etc.

var client = new ElasticLowLevelClient();

// the T in Search<T> is the response type
ElasticsearchResponse<Stream> response = client.Search<Stream>(
  "posts",
  "questions",
  new
  {
	  query = new
	  {
		  match_phrase = new
		  {
			  content = "Questions about C#"
		  }
	  }
  });

You can then check .Success to determine if the response is a successful one for the client. Elasticsearch.Net (and therefore NEST) has some rules around what a successful response is for a given request, for example, a 404 Not Found response for an index exists request is determined to be successful

if (!response.Success)
    throw new SomeException();

// will be a stream
var body = response.Body;

You should be aware however, not all responses can be determined to be error-free from the HTTP response and its status code alone. For example, a bulk response where in the process of performing some operations in the bulk request have errors, will return a 200 OK response; it's only by reading the response body can it be determined what the errors for those failed operations are.

[Martijn_Laarman]

Should add we also ship with VoidResponse which you can use for T which will close the response stream for you. As @forloop mentioned this is only possible for those API's where you do not need further response introspection.

Not closing/disposing the returned Stream will lead to connection leaks.