System.Text.Json serialization order

[bugproof]

AB#1166328
Serializer puts base properties at the end. In JSON net you could create a contract resolver that let you change serialization order.

class Entity
{
    public int Id { get; set; }
}

class Player : Entity
{
    public string Name { get; set; }
}

class Program
{
    static void Main(string[] args)
    {
        Console.WriteLine(System.Text.Json.JsonSerializer.Serialize(new Player {Id = 1, Name = "noname"}));
    }
}

the output will be:

{"Name":"noname","Id":1}

instead of

{"Id":1,"Name":"noname"} which is more readable

[ahsonkhan]

In JSON net you could create a contract resolver that let you change serialization order.

Do you have a scenario in which you need to control the serialization order where the current behavior/order is blocking you? I am asking to understand the help motivate the feature since JSON is generally unordered (i.e. folks shouldn't be relying on the ordering of the properties within the payload).

{"Id":1,"Name":"noname"} which is more readable

Is that the primary benefit? Having the payload written in a specific order so it is easier to read? Adding support for such capabilities would be a bit of work, and this alone doesn't seem worth the trade off (at least when prioritizing features for 5.0).

The contract resolver feature in Newtonsoft.Json has some other capabilities that are currently not supported. How are you controlling the serialization order today (and is that the only capability you need)? Can you please share a code snippet of your resolver.

If ordering is super critical for you, a workaround would be to create and register a JsonConverter<Player>.

public class PlayerConverter : JsonConverter<Player>
{
    public override Player Read(ref Utf8JsonReader reader, Type typeToConvert, JsonSerializerOptions options)
    {
        throw new NotImplementedException();
    }

    public override void Write(Utf8JsonWriter writer, Player value, JsonSerializerOptions options)
    {
        writer.WriteStartObject();
        writer.WriteNumber(nameof(value.Id), value.Id);
        writer.WriteString(nameof(value.Name), value.Name);
        writer.WriteEndObject();
    }
}

And here's how you can register and use it:

var options = new JsonSerializerOptions();
options.Converters.Add(new PlayerConverter());

Console.WriteLine(JsonSerializer.Serialize(new Player { Name = "noname", Id = 1 }, options));

[bugproof]

order is very helpful when testing the API with tools like insomnia, postman etc. you instantly see what's the most important at the top, and naturally ID comes first and it's later easier to navigate in code because you know that base properties come first... JSON is meant to be human-readable otherwise I wouldn't use it. The ordering would be only helpful for the developer and many existing APIs put Id as the first JSON property. Why is it hard to do?

code for resolver:

public class BaseFirstContractResolver : DefaultContractResolver
{
    public BaseFirstContractResolver()
    {
        NamingStrategy = new CamelCaseNamingStrategy();
    }

    protected override IList<JsonProperty> CreateProperties(Type type, MemberSerialization memberSerialization)
    {
        return base.CreateProperties(type, memberSerialization)
            .OrderBy(p => BaseTypesAndSelf(p.DeclaringType).Count()).ToList();

        IEnumerable<Type> BaseTypesAndSelf(Type t)
        {
            while (t != null)
            {
                yield return t;
                t = t.BaseType;
            }
        }
    }
}

no other benefits than readability, I think it would be more natural for base class properties to be serialized in the first place.

[stevendarby]

Have an unusual use case where we have one set of services in .NET for GETs and another set of services for write operations on another platform. We are doing ETag / If-Match checking by hashing JSON responses, so responses have to match across both platforms. It would be nice to be able to control this from the .NET side.

Also, if order really isn't important, could you consider putting the base properties first by default? This just seems to make more logical sense.

[Drawaes]

Hashing for cache invalidation/etag is also one I have come across. As it was a service to service scenario we moved to protobuf in the end to get the control over the order and bytes but that is not always possible for everyone

[layomia]

From @Jogge in #1085:

I'm missing an attribute for setting the order of the element in the JSON output.

Example:

I want the @SEGMENT to be the first element in the serialized JSON output of MyClass:

public abstract class MyBase
{
    [JsonPropertyName("@SEGMENT")]
    public virtual string Segment { get; set; } = "1";

    public int ID { get; set; }
}

public class MyClass : MyBase
{
    public string Name { get; set; }
}

The result when serializing MyClass is:

{
    "MyClass": {
    	"Name": "Foo",
    	"@SEGMENT": "1",
    	"ID": 42
    }
}

I would like the serialized JSON output to be:

{
    "MyClass": {
    	"@SEGMENT": "1",
    	"Name": "Foo",
    	"ID": 42
    }
}

or

{
    "MyClass": {
    	"@SEGMENT": "1",
    	"ID": 42,
    	"Name": "Foo"
    }
}

Json.NET has an attribute for this: https://www.newtonsoft.com/json/help/html/JsonPropertyOrder.htm

Related question: .NET core 3: Order of serialization for JsonPropertyName (System.Text.Json.Serialization)

[aktxyz]

+1 for this ... very helpful for DX to be able to have key things at the top

[neelabo]

(Reprinted from issue #33854)

Currently, the serialization order is not guaranteed.
I use Json to save application settings, but there is a problem if the order is not guaranteed.

• Diff cannot be obtained, making it difficult to find differences in settings.
• Not suitable for version control.
• The deserialization order is changed. -> The application initialization order is changed.

To fix the order, we propose the following enhancements:

• Extend so that alphabetical sort flag or sort function (IComparer<PropertyInfo>) can be set in JsonSerializerOptions. This option only affects the output.