WordPress REST API Dependency Injection: Request Context Patterns

Managing state across a single request in WordPress is notoriously messy. If you're building a headless application, you've likely hit the wall where global variables or static properties are the only way to pass data between your controllers, services, and middleware.

I recently spent about three days refactoring a bloated plugin that relied on static properties to track authenticated user context. It worked until we added a batch processing layer to our WordPress REST API Request Prioritization: Weighted Fair Queuing implementation; suddenly, state was leaking between parallel requests. Here is how I moved to a proper Request Context Injection pattern.

Why Standard DI Fails in WordPress

In a traditional Symfony or Laravel app, you have a long-running process where a Dependency Injection (DI) container can easily manage object lifecycles. WordPress, however, is a "shared-nothing" architecture that dies after every request.

We often try to hack DI by stuffing objects into $GLOBALS. This is fine for simple plugins, but it falls apart when you need to track request-specific metadata—like a custom Auth token or a resource-specific logger—across different hooks.

Implementing Request Context Injection

To solve this, I implemented a simple Context container that acts as a registry for the current request. Since PHP doesn't have native "thread-local storage" in the Java sense, we simulate it by using a static registry tied to the rest_api_init hook.

Here is the basic container structure:

PHP
class RequestContext {
    private static array $storage = [];

    public static function set(string $key, mixed $value): void {
        self::$storage[$key] = $value;
    }

    public static function get(string $key): mixed {
        return self::$storage[$key] ?? null;
    }
}

This is the foundation for a clean WordPress REST API architecture. Instead of pulling from the global scope, your services pull from the RequestContext.

Moving Beyond Static Globals

When I first architected this, I tried passing the container through every constructor. That turned into a dependency nightmare. My controllers ended up with six-argument constructors just to pass around a user context object.

Instead, I switched to a service locator pattern that initializes during the rest_api_init hook. This ensures that the context is scoped strictly to the REST lifecycle.

The Lifecycle Hook

PHP
add_action('rest_api_init', function() {
    $request = \WP_REST_Server::get_instance()->dispatch(new \WP_REST_Request());
    
    #6A9955">// Injecting services into the context
    RequestContext::set('logger', new RequestLogger());
    RequestContext::set('tenant', TenantManager::resolve());
}, 5);

By setting the priority to 5, I ensure these services are available before any controller attempts to access them. This is critical for headless WordPress setups where you might be handling custom JWT headers or specialized cache keys.

Integrating Request Context with Plugin Architecture

A robust plugin architecture requires that your internal services don't know how the data was retrieved, only that it is available. When I combine this with Distributed Locking in WordPress: Redis Mutex for REST APIs, I can store the lock metadata in the RequestContext so that cleanup hooks can release the lock regardless of where they were triggered in the request chain.

Handling Cross-Service Dependencies

The real power comes when you combine this with a lazy-loading factory. If your service needs a heavy object—like a database reader—don't instantiate it until the first time it’s accessed.

PHP
public static function getService(string $key): mixed {
    if (!isset(self::$storage[$key])) {
        self::$storage[$key] = ServiceFactory::create($key);
    }
    return self::$storage[$key];
}

This pattern keeps the memory footprint low, which is essential when you're running high-throughput headless endpoints.

Trade-offs and Lessons Learned

The biggest risk here is "context bloating." It’s tempting to throw everything into the RequestContext—the user, the post object, the current time, the weather. Don't do it. If you find yourself passing more than 5-6 items, your plugin is probably doing too much.

I’m still experimenting with how to handle unit testing for this pattern. Mocking static methods is a pain, and I’ve had to write a wrapper trait to clear the RequestContext between tests to ensure isolation. It’s not perfect, but it’s a massive upgrade over the alternative.

If you’re building complex REST endpoints, stop relying on globals. Use a scoped registry, keep your dependencies lazy-loaded, and watch your code become significantly easier to debug when the next traffic spike hits your headless frontend.