Deal with leading YangInstanceIdentifier fragment
Activity
Robert Varga December 11, 2023 at 9:49 PMEdited
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.
Robert Varga September 16, 2023 at 6:55 AM
This goes a bit deeper. RESTCONF essentially has two modes of parsing:
PUT, where we know the exact YangInstanceIdentifier of the resource
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.
Robert Varga October 25, 2022 at 6:25 PM
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.
We currently expect the inference to correctly point to the schema tree parent of the node that is being parsed.
This unfortunately is not entirely correct, as RESTCONF demonstrates: after parsing the data tree path (from URL), it also has to peek at the document to determine the additional YangInstanceIdentifier steps required for the document root to be reached and adjust the inference it passes to XmlParserStream. JSON codec does something different – it seems to be able to recover and we adjust the path after the parser result. See JsonNormalizedNodeBodyReader and XmlNormalizedNodeBodyReader for details.
What we really want to achieve is a single-pass parsing environment, where RESTCONF will give us the data tree identifier (e.g. YangInstanceIdentifier) and we figure out the missing steps as part of initialization – and communicate those back to it.