What input does the endpoint accept?
GET /ip/{ip} expects one IPv4 or IPv6 address. It is not a DNS resolver, subnet endpoint, comma-separated batch API, or CIDR calculator. Use a standard library parser rather than a custom regular expression because compressed IPv6 syntax and edge cases are easy to mishandle.
Where should validation happen?
Validate at the application boundary for immediate feedback and again before request construction when data crosses queues or storage. Keep the original event separate from the normalized address. URL-encode the final path segment with a structured URL API and avoid invoking shell commands with untrusted input.
How should invalid input be reported?
Return a controlled application error that identifies the field without echoing secrets or excessive raw request data. HTTP 422 should be counted separately from network and server failures because it requires corrected input, not backoff. Add fixtures for IPv4, compressed IPv6, full IPv6, and malformed values.
How should explicit address validation be implemented?
Use the runtime's standard IP parser to accept one IPv4 or IPv6 address and reject hostnames, CIDR notation, empty text, and address lists before URL construction. Keep this responsibility close to the IPRout client so the behavior documented in IPv4 and IPv6 Address Validation remains consistent across web requests, workers, and scheduled jobs.
How should explicit address validation be verified?
Cover common IPv4, compressed and expanded IPv6, loopback, malformed octets, repeated compression, whitespace, prefixes, and zone identifiers. Keep a 422 API fixture as the authoritative fallback. Automate the stable cases and reserve live checks for controlled environments so verification is repeatable without consuming unnecessary production allowance.
How should explicit address validation be operated?
Measure validation rejection by category without retaining unnecessary raw addresses. Sudden changes can reveal an upstream parsing regression or a caller sending the wrong field. Write down the owner and expected behavior so an alert or product change can be handled without reconstructing the original integration decisions.
Where does explicit address validation stop?
Local validation improves feedback and avoids wasted requests, but the API remains authoritative. Validation does not determine whether an address is public, useful, or appropriate for the product decision. Treat that limit as part of the feature contract and direct callers to the related guide when they need a different guarantee or control.
What belongs in the release review for explicit address validation?
Review the deployed implementation of IPv4 and IPv6 Address Validation, not only a local sample. Confirm the intended endpoint, credential source, timeout, response model, and fallback from the environment that will carry real traffic. Use the verification cases above as release evidence, inspect generated browser assets and logs for secret exposure, and make sure dashboards identify the workload without storing raw credentials or unnecessary IP data. Record the configuration owner and rollback action before enabling the feature broadly.
When should explicit address validation be revisited?
Revisit explicit address validation when traffic volume, plan capacity, application ownership, deployment regions, browser origins, data retention, or the product consequence of a lookup changes. Compare the current implementation with the documented operating boundary rather than assuming the original decision still fits. Update tests and internal runbooks together, then verify the public API contract and related IPRout guides before rolling the change across every service that shares the client or account.
External references
Continue with the standards and official documentation most relevant to this guide.