Optionally run validation rules during URL Parsing

[mikepizzo]

We added a rule-based validation for URLs similar to the rule-based validation we have for EdmModel. Users can write their own custom rules that target specific elements and the validation engine will run those rules against each instance of such a type within the parsed queries. We have default rules to detect: 1) Whether the query references deprecated members, and 2) Whether the query omits $select

Running this validation is an optional step the app can after the query has been parsed. However, running these rules requires re-traversing the parsed query, which is extra overhead. Instead, if we could evaluate the rules as we parse the query we could save overhead.

Assemblies affected

OData Lib 7.x

Additional detail

Currently, the public API exposes separate parse methods for different parts of the query. i.e., ParseTop, ParseSelectExpand, etc. The first time any of these methods is called, we parse the entire query and then return the requested part of the URL. We could add overloads to each of these to add an OData validator ruleset, or we could just add the optional ruleset to ParseUri to optionally do the validation.

[corranrogue9]

We could have a builder with a fluent API for this that still allows separating these without requiring retraversing the query after it's just been parsed, something like var parsedAndValidated = new ParseAndValidate().AddParsing().AddValidating().Execute()

[gathogojr]

Part of the challenge is that the public API for the URI parser has separate methods for ParseTop, ParseSelectExpand and so forth. The first time you call any of those methods, it's parses the whole URL and the other methods just return the appropriate portions of the parsed URI. That kind of hides where the parsing happens. We could consider having a Parse method and then, once you have parsed explicitly getting the individual elements of the parsed URI. That would make it clear where the parse is occurring and you might add validation. Changing the API would not be a big issue but it'd be a breaking change.