Prompt and context
The team wants URI Templates for API documentation, pagination links, and batch-query URLs such as /users{?status,limit}. Templates come from configuration while some variable values come from users. Explain RFC 6570 expression levels, reserved-character and list expansion, and the security boundaries for parsing, expanding, and validating the result.
What the interviewer is testing
- Separating template syntax, variable encoding, and final-URI parsing and validation.
- Explaining the difference between simple, reserved, path, matrix-parameter, and query expansion.
- Handling lists, associative maps, explode, prefix truncation, and undefined variables.
- Recognizing SSRF, path traversal, open redirects, and data-leak risks from untrusted templates.
Questions to clarify first
- Are templates static code, reviewed configuration, or tenant/user supplied?
- Are results displayed only, or sent directly by a server-side HTTP client?
- Are variables strings, lists, associative maps, or nested JSON?
- Which schemes, hosts, ports, and path prefixes are allowed; must the result stay on the current API origin?
- Must the implementation support all RFC 6570 levels, or only an approved operator subset?
A 30-second answer framework
I would separate template parsing, variable encoding, and final-URI policy. First define supported RFC 6570 operators and value types, then apply percent-encoding, list, and associative-map expansion per operator; undefined variables should be omitted according to the specification. Treat every expanded value as an untrusted URI, parse and validate its scheme, host, port, and normalized path, and never let a template choose an arbitrary server-side network target. Tests would cover reserved characters, Unicode, empty values, repeated keys, prefixes, and hostile paths.
Step-by-step deep answer
Step 1: Define the URI Template boundary
URI Template is syntax for expressing a URI-reference with variables. It is not an HTTP client, URL allowlist, or business router. The implementation must parse literals and expressions before producing a result from values; it must not concatenate the template into a request or treat the expanded value as an already safe URL.
Step 2: Implement operators by level
RFC 6570 starts with simple variable expansion and adds reserved-character, fragment, label, path-segment, matrix-parameter, query, and query-continuation forms. Common operators include +, #, ., /, ;, ?, and &. Operators define separators, empty-value behavior, and which reserved characters may remain; one generic string-replacement rule is insufficient.
Step 3: Handle encoding and composite values
Reserved characters in a simple string are percent-encoded according to the expression. A list can be comma-joined or exploded into repeated parameters; associative maps have their own key/value separators. A prefix modifier takes a string prefix and must not be mistaken for a Unicode-character count, byte count, or safe truncation. Specify behavior for UTF-8, empty strings, and undefined variables.
Step 4: Isolate template and variable sources
Static, code-reviewed templates can support more operators; tenant configuration should restrict expressions, variable names, and output components. Values may come from a request, but a template must not call functions, read environment variables, or compose an arbitrary scheme. Keep the template AST separate from the value map so a variable name cannot inject new expression syntax.
Step 5: Validate the final URI
After expansion, use a standard URI parser for scheme, authority, path, query, and fragment. For server-side requests, scheme, host, and port must match an allowlist; DNS resolution must also block loopback, link-local, and private addresses, and redirects must be checked again. Normalize the path before checking its allowed root so encoded .. cannot bypass the rule.
Step 6: Make API links maintainable
Pagination templates should specify which variables are server-generated, while filters use fixed variable names and types. Do not put signatures, access tokens, or internal hostnames into public templates or results. Record template versions, variable schemas, and expansion errors. If stable ordering is required, the business layer must provide it rather than relying on parameter-string order.
Step 7: Build tests and monitoring
Test every operator with single values, lists, maps, empty values, and undefined values against the specification examples. Add reserved characters, Unicode, repeated query keys, long prefixes, double encoding, %2e%2e, alternate schemes, redirects, and DNS-resolution cases. Monitor expansion failures, rejection reasons, destination-origin distribution, and abnormal lengths, and trigger review when template configuration changes.
High-quality sample answer
I would first restrict the supported RFC 6570 operators and separate the template AST, variable schema, percent-encoding, and final URI validation. Lists, maps, explode, and prefixes follow their individual rules, and undefined variables are omitted; values cannot be reparsed as expressions. Every result remains an untrusted URI: parse it, allow only the API's scheme, host, port, and normalized path, block private addresses for server-side requests, and recheck every redirect. Tests cover RFC examples, Unicode, empty values, repeated keys, double encoding, traversal, and SSRF, with template versions and rejection reasons recorded.
Common mistakes
- Replacing operator semantics with string concatenation and breaking separators or percent-encoding.
- Treating
+reserved expansion as “no encoding at all” and ignoring component boundaries. - Treating lists, maps, and explode as one comma-joining format.
- Validating only template text instead of the expanded scheme, host, port, and normalized path.
- Treating URL encoding as SSRF protection and following redirects without revalidation.
Follow-up questions and responses
Follow-up 1: What should happen to an undefined variable?
Omit the undefined variable and the necessary separator according to the expression. Do not render the string null. If the business schema requires the variable, reject it before expansion.
Follow-up 2: Why not call one URL-encode function?
Encoding depends on the expression and URI component. Query parameters, path segments, and reserved expansion have different separators and rules. One function cannot decide composite values, empty values, prefixes, and operators.
Follow-up 3: How do you reduce risk for tenant templates?
Use a reviewed operator subset, fixed variable schema, and fixed output components. Disallow arbitrary schemes or authorities, then still enforce origin allowlists, path normalization, DNS/IP checks, and redirect revalidation after expansion.
Follow-up 4: Can a prefix modifier truncate a secret?
It is URI Template string-prefix semantics, not privacy masking or Unicode-safe truncation. Mask sensitive data in the business layer, where length and character boundaries are explicit policy.
Follow-up 5: How do you prove RFC 6570 compatibility?
Run the RFC 6570 specification examples and operator-level tests, compare expected expansion for each variable type, then add project-specific rejection cases and document unsupported levels and differences.