roundtrip unrecognized JSON properties

[LukasPaczos]

Refs mapbox/mapbox-directions-swift#637.

We should find a way to keep and serialize back any, at the time of serializing, unrecognized properties to support forward compatibility.

cc @1ec5 @SiarheiFedartsou @Guardiola31337

[1ec5]

In principle, persisting and roundtripping unrecognized properties would be beneficial to any models that correspond to server API responses. It’s particularly needed for the Directions and Map Matching APIs, which may return undocumented response properties that Navigation Native may want to consume. However, multiple APIs routinely introduce beta request options that result in beta response properties.

Similarly, GeoJSON has a provision for foreign members, acknowledging that GeoJSON authoring tools often extend GeoJSON objects with arbitrary properties. Sometimes foreign members are vendor-specific, while sometimes they’re defined by separate standards like GeoJSON-T and TopoJSON. mapbox/turf-swift#175 added Swift support for round-tripping foreign members (but not interpreting them); it would be nice to support them consistently across languages.

The Geocoding API represents most of a result feature’s metadata as foreign members in a GeoJSON-compliant response format, so foreign member support could allow us to remove custom Geocoding API response handling code.

[LukasPaczos]

Tagging @tobrun who is also looking into this.

[vadzim-vys]

We can add support of unrecognised properties to the generated type adapters. The type adapters we use are generated by auto-value-gson library. What if we fork it and add support of unrecognised json properties. It shouldn't be too hard to generate handling of unrecognised properties in our type adapters.

Discussion with library's authors: rharter/auto-value-gson#266. Spoiler: they didn't like the idea.

[vadzim-vys]

PR: #1394

[vadzim-vys]

Waiting for the official fork to be created + need to reconsider with team where to store binary artefacts from the fork.

[1ec5]

The performance impact mentioned in rharter/auto-value-gson#266 (comment) is a valid concern. This is one reason why many GeoJSON libraries opt not to support foreign members. We’re seeing a performance hit adding support for foreign members in Directions API responses containing GeoJSON-formatted geometries: mapbox/mapbox-directions-swift#669 (comment). Since we don’t expect these GeoJSON geometries to contain any meaningful foreign members for the foreseeable future, we’re considering selectively processing foreign members in the overall Directions API response but not in the geometry properties that could be more complex: mapbox/turf-swift#186.

[vadzim-vys]

I will try to measure performance impact of new changes then