Rate limiting in API context logic

Wouter-Red-Falcon

So my logic to handle the API context and keep it up-to-date is as follows:

public static function loadApiContext()
{
    $filePath = BUNQ_API_CONTEXT_PATH;
    if (!static::validateExistingContext($filePath))
    {
        $apiContext = ApiContext::createForPsd2(
            BunqEnumApiEnvironmentType::PRODUCTION(),
            SecurityUtil::getCertificateFromFile(PSD2_SIGNING_CERTIFICATE_PATH),
            new PrivateKey(static::getPrivateKey()),
            [SecurityUtil::getCertificateFromFile(PSD2_CA_CHAIN_PATH)],
            DESCRIPTION
        );
        $apiContextJson = $apiContext->toJson();
        Storage::put($filePath, $apiContextJson); // Laravel storage (verified to be working).
        BunqContext::loadApiContext($apiContext);
    }
}

protected static function validateExistingContext($filePath)
{
    if (Storage::exists($filePath))
    {
        $apiContextJson = Storage::get($filePath); // Retrieve existing context from storage.
        $apiContext = ApiContext::fromJson($apiContextJson);

        try
        {
            $currentContext = BunqContext::getApiContext();
            if ($currentContext->getApiKey() === $apiContext->getApiKey())
                return true;
        }
        catch (BunqException $e) { }

        if ($apiContext->ensureSessionActive())
        {
            $apiContextJson = $apiContext->toJson();
            Storage::put($filePath, $apiContextJson);
        }
        BunqContext::loadApiContext($apiContext); // Source of error.

        return true;
    }

    return false;
}

This occasionally leads to a TooManyRequestsException on the final BunqContext::loadApiContext in validateExistingContext. This is due to the User::listing call in UserContext.

Now I'm wondering if anyone can see a flaw in the methods I'm using. This seems to happen sometimes when the context doesn't even need to be refreshed.

Thanks for any help!

wesselt

@Wouter-Red-Falcon#137920 Now I'm wondering if anyone can see a flaw in the methods I'm using.

Yeah, there's a limit of N per 3 minutes I think. Your program doesn't know when bunq's 3 minute window starts or ends, so It's entirely random at which point in your program the limit will be hit. If part of your validation is a web service call, that would add one towards the limit.

One option is to cache information. You can store user information, so that if it's requested again within a short time period, you return it without making an API call. This makes your program much more complex because you're now storing state locally.

Another option is to reduce the number of API calls. For example, if you now validate the connection with an API call, you could limited that validation to once every hour.

Wouter-Red-Falcon

@wesselt Thanks! Though I believe the rate limiting is 2-5 calls per 3 seconds per endpoint. We're already fetching the minimum amount of data we need to keep our user's overview up-to-date, so further caching isn't an option. I'm just wondering if there's a issue specifically with the logic of the two methods I posted that would generate this amount of calls and result in the error.

wesselt

@Wouter-Red-Falcon#137926 The ensureSessionActive call stands out. Might that be calling the same endpoint repetitively?