Verbruikslimieten in PHP-API's beschermen de beschikbaarheid en de kosten van de dienst, maar een slecht ontworpen beleid kan legitieme integraties onderbreken. Om het goed aan te pakken, volstaat het niet om een aantal verzoeken per minuut vast te leggen: je moet bepalen wie verbruikt, welke bewerking wordt uitgevoerd, welke resource risico loopt en hoe het daadwerkelijke verkeer zich gedraagt.
Een effectief ontwerp combineert limieten die passen bij het gebruikspatroon, consistente tellers tussen instanties en antwoorden waarmee de afnemer kan herstellen. Het vereist ook dat je het effect van de regels observeert voordat je ze aanscherpt, vooral wanneer meerdere klanten dezelfde inloggegevens delen of afhankelijk zijn van gemeenschappelijke resources.
Maak onderscheid tussen verzoekfrequentie, quota en gelijktijdigheid
Deze controles beschermen tegen verschillende problemen en zijn niet onderling uitwisselbaar:
- Verzoekfrequentie: beperkt hoeveel verzoeken binnen een kort interval worden geaccepteerd. Dit helpt om pieken of aanhoudend verkeer dat de applicatie overbelast, in te perken.
- Cumulatief quota: beperkt het totale verbruik over een langere periode, bijvoorbeeld een aantal bewerkingen per dag of factureringscyclus. Dit is geschikt om contractueel gebruik of opeengestapelde kostbare workloads te beheren.
- Gelijktijdigheid: beperkt hoeveel bewerkingen tegelijkertijd worden uitgevoerd. Dit is nuttig wanneer elke bewerking gedurende lange tijd workers, verbindingen of resources in beslag kan nemen.
Een klant kan zich aan een limiet voor de verzoekfrequentie houden en toch veel langdurige bewerkingen tegelijk opstapelen; ook kan een klant weinig verzoeken uitvoeren die een kostbaar dagquotum verbruiken. Kies de controle op basis van het risico dat je wilt beperken en leg, als er meerdere nodig zijn, vast hoe ze op elkaar inwerken en welke als eerste wordt toegepast.
Bepaal welke identiteit en resource je wilt limiteren
De sleutel voor de limiet moet een verbruikseenheid vertegenwoordigen die operationeel zinvol is. Afhankelijk van het product kan dit een credential, gebruiker, organisatie, clientapplicatie, route of combinatie daarvan zijn. Limiteren op basis van alleen het IP-adres kan gedeelde netwerken benadelen en maakt geen goed onderscheid tussen geauthenticeerde afnemers; een IP-adres kan als aanvullend signaal dienen voor anoniem verkeer of beveiligingscontroles.
Voor geauthenticeerde klanten is het verstandig het beleid te koppelen aan een stabiele identiteit en isolatie tussen organisaties toe te passen. Een credential die door meerdere systemen wordt gedeeld, kan verhullen wie een piek veroorzaakt: gebruik waar mogelijk afzonderlijke credentials of voeg dimensies toe waarmee je het verbruik kunt toewijzen. Neem geen onbewerkte geheimen op in teller- of logsleutels.
Niet alle routes hebben dezelfde kosten. Een eenvoudige query en een uitgebreide export hoeven niet noodzakelijk hetzelfde budget te verbruiken. Je kunt gewichten of verschillende beleidsregels toewijzen aan kostbare bewerkingen, zolang het criterium voor afnemers begrijpelijk en consistent is. Controleer ook de limieten van de dienst: een API kan weinig verzoeken ontvangen en toch een gedeelde afhankelijkheid, zoals een database of externe provider, overbelasten.
Kies vensters die het gebruikspatroon weerspiegelen
Een vast venster is eenvoudig uit te leggen, maar kan een piek aan het einde van een interval toestaan, gevolgd door een nieuwe piek aan het begin van het volgende interval. Een schuivend venster beperkt dit effect, maar vereist meer opslag- en rekenwerk. Een token-systeem staat beperkte pieken toe en houdt de gemiddelde verzoekfrequentie onder controle; dit is nuttig wanneer legitiem verkeer in golven binnenkomt. De keuze hangt af van het verbruikspatroon en de vereiste nauwkeurigheid.
Verwar een legitieme activiteitspiek niet met misbruik. Geplande workloads, synchronisaties aan het begin van de werkdag of nieuwe pogingen na een onderbreking kunnen verzoeken concentreren. Als het product pieken toestaat, definieer dan expliciet de omvang ervan en hoe lang het duurt voordat het budget is hersteld. Beperk bij langdurige bewerkingen ook de gelijktijdigheid of pas toelatingscontrole toe voordat schaarse resources in gebruik worden genomen.
Ook retries van de client zijn van belang. Als een tijdelijk antwoord onmiddellijk nieuwe pogingen uitlokt, kan de limiet de piek verergeren. Adviseer een geleidelijk oplopende wachttijd, idealiter met willekeurige variatie, en bepaal of herhaalde bewerkingen met dezelfde idempotency key als nieuwe verzoeken tellen of als veilige herhaling.
Stem tellers op elkaar af wanneer PHP op meerdere instanties draait
Een teller die alleen in het procesgeheugen wordt opgeslagen, kan op één instantie werken, maar verliest zijn consistentie wanneer verkeer over meerdere instanties wordt verdeeld. Elke server kan dan een deel van de limiet accepteren, waardoor het totaal de limiet overschrijdt. In deployments met meerdere instanties moet de status worden gecoördineerd via een gedeelde opslag of een gelijkwaardig mechanisme met geschikte atomaire bewerkingen.
Ontwerp ook het gedrag bij storingen van het tellersysteem. Als dat systeem niet beschikbaar is, kan het afwijzen van alle verzoeken legitieme klanten onderbreken; alles accepteren kan een kritieke afhankelijkheid blootstellen. De keuze hangt af van het risico van de route: voor een query met weinig impact kan een andere fallback redelijk zijn dan voor een bewerking die hoge kosten veroorzaakt. Documenteer het criterium en waarschuw bij degradatie.
Vermijd tellersleutels die te algemeen zijn en organisaties of routes samenvoegen, maar ook sleutels die zo versnipperd zijn dat het totale verbruik moeilijk te beheren wordt. Stel vervaldatums en opschoning van de status in, zodat tijdelijke sleutels zich niet onbeperkt opstapelen. Controleer dat configuratiewijzigingen tellers niet onverwacht opnieuw instellen of dupliceren.
Communiceer de afwijzing als onderdeel van het API-contract
Geef bij het bereiken van een limiet een HTTP-statuscode terug die past bij het API-contract — doorgaans 429 Too Many Requests voor een beperking van de verzoekfrequentie — en een gestructureerde body die het type limiet aangeeft zonder interne informatie prijs te geven. Gebruik deze statuscode niet misleidend als de bewerking om een andere reden wordt afgewezen.
Geef nuttige aanwijzingen voor herstel, zoals het geschatte moment waarop opnieuw proberen mogelijk is of de limiet- en verbruiksgegevens die in het contract zijn vastgelegd. Als je Retry-After verstuurt, zorg er dan voor dat de opgegeven wachttijd geldig is. Houd antwoorden consistent tussen routes en maak geen tellers van andere klanten zichtbaar. Afnemers moeten een tijdelijke afwijzing kunnen onderscheiden van fouten met authenticatie, validatie of beschikbaarheid.
Observeer de impact en pas het beleid aan op basis van bewijs
Registreer geaccepteerde en afgewezen verzoeken, de identiteit of het klantsegment op veilige wijze, de route, het toegepaste beleid en de reden. Meet ook de latency, gelijktijdigheid en belasting van relevante afhankelijkheden. Sla geen credentials of onnodige persoonsgegevens op; gebruik beschermde of geaggregeerde ID's wanneer die volstaan voor de analyse.
Een toename van afwijzingen bewijst op zichzelf niet dat de drempel te streng is. Zoek naar patronen: getroffen klanten, tijdstippen, routes, duur van bewerkingen en retries achteraf. Onderzoek signalen van false positives, zoals afwijzingen die zich concentreren bij organisaties met gedeelde credentials of bij geplande taken. Pas telkens één variabele aan en zorg dat je de wijziging kunt terugdraaien.
Voer het beleid geleidelijk in
Evalueer het beleid met gebruiksgegevens en test representatieve scenario's voordat je een limiet afdwingt. Als de architectuur het toelaat, registreer dan welke verzoeken zouden zijn afgewezen zonder ze daadwerkelijk te blokkeren; deze observatie vervangt geen loadtests en garandeert niet dat historische gegevens alle pieken voorspellen.
- Bepaal welk risico je wilt beheersen en of een limiet voor de verzoekfrequentie, quota, gelijktijdigheid of een combinatie daarvan passend is.
- Stel limieten in per identiteit en resource en controleer de isolatie tussen gebruikers en organisaties.
- Test pieken, trage bewerkingen, retries, gedeelde credentials en storingen van de telleropslag.
- Controleer of meerdere instanties de limiet gecoördineerd toepassen en of tijdelijke status wordt opgeschoond.
- Valideer het afwijzingsantwoord, de aanwijzingen voor nieuwe pogingen en de compatibiliteit met huidige afnemers.
- Monitor afwijzingen, latency en afhankelijkheden; communiceer wijzigingen die integraties kunnen beïnvloeden.
Verbruikslimieten in PHP-API's moeten zowel het platform als de continuïteit voor klanten beschermen. Het beste beleid is niet het strengste, maar het beleid dat risico beheerst met regels die aan verbruikers kunnen worden toegeschreven, voorspelbare antwoorden en voldoende bewijs om ongewenste effecten te corrigeren.
