The trouble here is that NormalizedNodeResult, from whence we take the resulting payload is a NormalizedNode implementation contract, which is not concerned with actual addressing.

The contract here revolves around XmlParserStream.parse() and JsonParserStream.parse(): these are invoked after setting up the pipeline and end up processing a single document. As such, their current return value, which is the stream itself, is never used.

As such, we need to define some sort of interface that both parsers implement, so that aside from setup (which should be a staged builder), the final bit of execution and evaluating the result is the same.

This goes a bit deeper. RESTCONF essentially has two modes of parsing:

1. PUT, where we know the exact YangInstanceIdentifier of the resource
2. POST, where we know the YangInstanceIdentifier of the parent (sans the prefix mentioned here)

At least the XML codec fails to detect when the body of a PUT request does not match the identifier, for which we have a rather ugly dance (involving first parsing to org.w3c.dom.Document).
At the end of the day, I think we can get away with just providing two static methods, which will do the correct thing – so that we do not have to worry about the intermediate setup leaking.

The first method should deal with a PUT, validating whether the document element matches the requested Inference. There is a twist here, as while this method is universally useful, the way it deals with empty YangInstanceIdentifier is different between NETCONF and RESTCONF – while the former wants a revision of SchemaContext.NAME, the latter wants the ietf-restconf:name.
The second method should deal with a POST, and should be returning the path prefix described above.

There is also a slight wrinkle we need to deal with: PUT on YangInstanceIdentifier.empty() needs to take an expected NodeIdentifier, as the datastore resource in RESTCONF has a different name than in NETCONF.
We therefore need two methods here – and the one taking YangInstanceIdentifier must reject empty instance identifiers with IAE.

We should capture this contract in an interface ... somewhere, somehow.