[EndpointUri PR 4/4] Optimize EndpointUri creation by pre-parsing urls in codegen

[alextwoods]

This is PR 4/4 for replacing Uri.create in endpoint resolution with the light weight EndpointUrl.

Note: This PR merges to feature/master/endpoint-remove-uri and NOT to master

Previous PRs:

• [EndpointUri PR 1/4] Add EndpointUrl class #7155
• [EndpointUri PR 2/4] Switch runtime consumers to EndpointUrl #7158
• [EndpointUri PR 3/4] Update codegen to use the EndpointUrl #7160

Modifications

Adds EndpointUrlCodeEmitter to the rules2 codegen pipeline, which analyzes endpoint URL expression trees at code generation time and emits EndpointUrl.fromComponents(scheme, host, port, path) instead of EndpointUrl.fromString(fullUrl) wherever possible. This eliminates runtime string parsing for the vast majority of resolved endpoints.

Background: Endpoint URL expressions

Endpoint rules define the Endpoint Object uri property as strings that include template strings.

"url": "https://sts.{Region}.{PartitionResult#dnsSuffix}"

The Java SDK ExpressionParser.parseStringValue() tokenizes these templates, splitting on {...} boundaries to produce a StringConcatExpression — a list of alternating literals and variable/member-access references:

StringConcatExpression([
    LiteralStringExpression("https://sts."),
    VariableReferenceExpression("Region"),
    LiteralStringExpression("."),
    MemberAccessExpression(source=VarRef("PartitionResult"), name="dnsSuffix")
])

License

• I confirm that this pull request can be released under the Apache 2 license

[RanVaknin]

I think we should really add some conformance testing that compares the runtime resolved endpoint against the build time resolved endpoint. (and also the individual getters like .host(), .port() , etc) This has a huge blast radius and those would give us some more confidence before rolling out this change.

Going forward we will be hand maintaining both runtime and buildtime endpoint resolution codepaths that each have their own nuanced (but allegedly equivalent) implementation. If we go to update one of these implementations in the future we might introduce a drift in logic. Conformance testing will help mitigate that risk (and perhaps adding javadoc to make this divergence more visible for future work)

[alextwoods]

I've added some conformance tests in the codegen-generated-classes-test package that ensure resolved Endpoints match in uri, EndpointUrl.fromString and EndpointUrl.fromComponents cases.

However - the real testing that I think protects us is the standard generated endpoint tests for every service's endpoint rules. We require 100% coverage of leaf nodes (eg, Endpoints) and those tests assert that the URI matches the expected so any change in codegen, EndpointUri.fromString/fromComponent or new service endpoint will get tested.

[github-actions]

This pull request has been closed and the conversation has been locked. Comments on closed PRs are hard for our team to see. If you need more assistance, please open a new issue that references this one.