Request Serialization in NEST 6

I used to be able to log the output of the old Client.Serializer and paste it right into Dev Tools in Kibana 5.x and earlier. Now SourceSerializer.SerializeToString outputs all possible fields with null values and pasting it into Dev Tools results in parsing errors. I am able to get the old output I was expecting if I get the RequestBodyInBytes from the response.ApiCall, but I need the request without executing it for our saved searches architecture (sins of the past).

Thanks for any assistance you can offer.

Hey @thespatt

The RequestResponseSerializer on IElasticClient is the one to use for this purpose

public class MyDocument 
{
    public MyDocument(int id) => Id = id; 
    public int Id { get; set; }      
    public string Message { get; set; }
}

var client = new ElasticClient();

var search = new SearchDescriptor<MyDocument>()
	.Query(q => q
		.Match(m => m
			.Field(f => f.Message)
			.Query("is it me you're looking for?")
		)
	);
	
var json = client.RequestResponseSerializer.SerializeToString(search);

Console.WriteLine(json);

which writes out

{
  "query": {
    "match": {
      "message": {
        "query": "is it me you're looking for?"
      }
    }
  }
}

In NEST 6.x, with the internalization and renamespacing of Json.NET, a distinction was made between the serializer to use for NEST request and response types, and the one to use for properties that relate to types that you control, for example, _source in responses, terms input to terms query, etc. With this distinction and separation, there are two serializer properties exposed on IElasticClient:

  1. RequestResponseSerializer

    used to serialize NESTs request and response types

  2. SourceSerializer

    used to serialize your types, including properties on request and response types that relate to your types

With default serialization, both properties will actually use the same serializer, but when custom serialization is used, the SourceSerializer will be assigned with custom serializer hooked up, such as JsonNetSerializer.

One of the side effects of the internalizing of Json.NET is that by default, NEST now has no knowledge of how to serialize Json.NET types such as JObject, JArray, etc. because the types internally are renamespaced, making them different types. To allow serialization of these types to work as before, and allow users to define their own Json.NET serialization settings without affecting NEST, the nuget package NEST.JsonNetSerializer can be used and the JsonNetSerializer hooked up as the serializer..

There is much more that we aim to do with serialization of which internalizing Json.NET is the first step!

@forloop Thanks, I can't believe I missed that. I had it at one time but must have changed it. In any case thanks for the great explanation it's exactly what I needed.

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.