JsonPropertyPath attribute to enable hoisting nested JSON to a top-level type

[hwoodiwiss]

Currently, when provided with a hierarchical JSON payload, System.Text.Json provides 2 options for accessing deeply-nested properties within that data:

• Matching the JSON hierarchy with a type hierarchy
• Using the JSON DOM apis and navigating to the property

For a given JSON Payload:

{
  "action": "published",
  "registry_package": {
    "owner": {
      "login": "hwoodiwiss"
     },
    "package_version": {
      "container_metadata": {
        "tag": {
          "name": "latest"
        }
      }
    }
  }
}

Where I've only added the fields, I'm interested in, these approaches can generate a significant amount of boilerplate code or extra types to match the hierarchy.

A useful additions to System.Text.Json would be the ability to use JSON Path as an attribute, and hoist the properties up to a single type. In my opinion this would have great utility in use cases where you are not in control of the JSON you will be receiving, and the JSON you are receiving contains a large number of fields or levels of hierarchy that you do not want or need.

An example usage of what I'm envisioning for the above payload would look like:

public class RegistryPackagePublished
{
    [JsonPropertyName("action")]
    public string Action { get; init; }

    [JsonPropertyPath("$.registry_package.owner.login")]
    public string? OwnerLogin { get; init; }

    [JsonPropertyPath("$.registry_package.package_version.container_metadata.tag.name")]
    public string? PackageTag { get; init; }
}

[TonyValenti]

What we do is we have two "Json" types. The "raw" which is exactly what we get from the web service and the "regular" one which is what we reform it to be. In our code that fetches the raw, we immediately transform it so the raw is never actually exposed.

[hwoodiwiss]

Hey Tony, sorry if I've misunderstood, it sounds like your describing mapping the incoming API request type to a more meaningful internal type that you then flow through the layers of your app?

If so, I think the request type would still have the described boilerplate issue where you have to model the structure of the incoming request to retrieve nested objects. My aim with this would be to enable a lighter weight wire-DTO, that I would still then likely map to a more meaningful internal type.