Request Identification with Key Resolvers

Your learning outcome for this lesson:

You will implement a key resolver to identify a request by its endpoint path. This capability is the cornerstone of applying different rate limits to different parts of your API, allowing you to protect expensive operations more strictly than cheaper ones.

1. Why Rate Limit by Endpoint?

Before we jump into the code, let's establish why this is so important in a real-world system. Not all API endpoints are created equal:

• A GET /api/products endpoint might be a lightweight database read, capable of handling hundreds of requests per minute.
• A POST /api/orders endpoint could trigger a complex workflow involving payment processing, inventory updates, and sending notifications. This is an expensive operation that you'd want to limit more strictly.
• A POST /api/users/reset-password endpoint is a security-sensitive operation that should be heavily restricted to prevent abuse.

By generating a rate-limiting key based on the endpoint path (e.g., /api/products), we can later create a configuration that maps these specific paths to different rules. This gives us fine-grained control over our API's usage and protection. This is a standard pattern in API gateways and production infrastructure.

2. Accessing the Request Path in an Interceptor

Our RateLimitKeyResolver interface provides the resolve(HttpServletRequest request) method. This HttpServletRequest object is our gateway to all information about the incoming request, including its path.

The key method we need is request.getRequestURI(). This method returns the part of the URL from the protocol name up to the query string.

For example, for a request to http://localhost:8080/api/users/123?verbose=true, request.getRequestURI() would return the string "/api/users/123".

The video below provides a practical demonstration of working with the HttpServletRequest object inside an interceptor, similar to our RateLimitingInterceptor.

This confirms that getting the path is straightforward. Now, let's implement the resolver.

3. Implementing the EndpointPathResolver

Create a new Java class named EndpointPathResolver. This implementation will be concise, but its role in the overall architecture is significant.

import jakarta.servlet.http.HttpServletRequest;
import org.springframework.stereotype.Component;

/**
 * Resolves the rate-limiting key from the request's URI.
 * This allows for applying rate limits on a per-endpoint basis.
 */
@Component("endpointPathResolver")
public class EndpointPathResolver implements RateLimitKeyResolver {

    @Override
    public String resolve(HttpServletRequest request) {
        // Return the URI of the request, which uniquely identifies the endpoint path.
        // For example, for a request to "http://example.com/api/users?id=1",
        // this will return "/api/users".
        return request.getRequestURI();
    }
}

Key Points:

• @Component("endpointPathResolver"): We register this as a Spring bean with a unique name, allowing us to easily inject it into our RateLimitingInterceptor or other components.
• request.getRequestURI(): This single method call is all we need. It reliably extracts the path, which serves as a perfect key for endpoint-specific rules.

To visualize what part of the URL getRequestURI() captures, consider the following diagram. It focuses on the path segment of the URL.

4. Industry Validation and Nuances

Our approach is a common industry practice. The article below discusses implementing rate limiting and explicitly shows how the request path is used to form a unique key.

A Quick Note on Alternatives

You might see other implementations that use reflection to get the controller's method name (e.g., method.getName()) as the key. The article How I Built a Simple Rate Limiter... (resource_id: LINK) from our resource pool uses this technique.

While that works, using request.getRequestURI() is often more robust for two reasons:

1. Specificity: Multiple URL paths can be mapped to the same controller method (e.g., /api/orders and /api/legacy-orders). Using the URI allows you to rate-limit them differently, whereas method.getName() would treat them as the same.
2. No Reflection: It avoids the slight performance overhead and complexity of using Java reflection to inspect the handler method.

Our current implementation is simple, direct, and highly effective.

Key Takeaways

• You've implemented an EndpointPathResolver using request.getRequestURI() to identify requests by their path.
• You understand the importance of this strategy for applying fine-grained rate limits to different API endpoints based on their cost or sensitivity.
• This new resolver fits perfectly into our RateLimitKeyResolver strategy pattern, further enhancing the flexibility of our system.
• You've seen that this approach is validated by common industry practices for building rate limiters and API gateways.

Next Steps

Excellent work! We now have resolvers that can identify a client by API key, user ID, or the endpoint they are trying to access. Each of these strategies is powerful on its own. However, the true power of a multi-tenant system comes from combining them.

In our next lesson, we will create a composite key resolver that combines multiple identifiers. This will allow us to enforce rules like "limit user 'test-user' to 10 requests per minute on the /api/orders endpoint," unlocking a new level of control for our rate limiter.