# DRF Throttling: Scope gebruiken – Vergelijking tussen ScopedRateThrottle en UserRateThrottle‑subclass

In DRF komen twee veelvoorkomende patronen voor bij scope‑gebaseerde throttling.

* **Patroon A**: Maak een eigen klasse door `UserRateThrottle` (of `SimpleRateThrottle`) te erven, stel een `scope` in en koppel deze direct aan de view via `throttle_classes`.
* **Patroon B**: Registreer `ScopedRateThrottle` in `DEFAULT_THROTTLE_CLASSES` en geef in de view alleen `throttle_scope = "login"`.

**Vraag:** "Is het uiteindelijk hetzelfde?"

> **Voor een enkel rate‑limiet gebaseerd op ‘userID (of niet‑geauthenticeerde IP) + scope’ zijn de resultaten vrijwel identiek.**
> Verschillen ontstaan in de manier van toepassen (foutpreventie), uitbreidbaarheid (meerdere policies/aanpassingen) en de code‑structuur (configuratie‑gericht vs code‑gericht).

---

## 1. Gemeenschappelijke basis: Beide gebruiken “scope + (userID of IP)” als sleutel {#sec-431a00e0f2d6}

* `ScopedRateThrottle` bouwt de sleutel uit `scope + userID/IP` wanneer `throttle_scope` aanwezig is, en zoekt de bijbehorende rate in `DEFAULT_THROTTLE_RATES`.
* `UserRateThrottle` beperkt standaard op `userID` voor geauthenticeerde gebruikers en op IP voor niet‑geauthenticeerde. Voor meerdere scopes wordt aanbevolen een subclass te maken.

---

## 2. Verschil 1: Waar wordt de scope gedefinieerd? – View‑attribuut vs Class‑attribuut {#sec-d624b1b24a23}

### Patroon A: Scope vast in de klasse (expliciet) {#sec-8806ad9d3f5f}

```python
from rest_framework.throttling import UserRateThrottle
from rest_framework.views import APIView

class CustomDomainSaveThrottle(UserRateThrottle):
    scope = "custom_domain_save"

class SaveCustomDomainView(APIView):
    throttle_classes = [CustomDomainSaveThrottle]
```

* De scope is **vast in de klasse**.
* De view hoeft alleen aan te geven dat deze klasse gebruikt wordt.
* Minder kans op typfouten in de scope‑string; de klasse fungeert als documentatie.

### Patroon B: Scope in de view, gedeelde throttle (configuratie‑gericht) {#sec-21174dce63ed}

```python
REST_FRAMEWORK = {
  "DEFAULT_THROTTLE_CLASSES": [
    "rest_framework.throttling.ScopedRateThrottle",
  ],
  "DEFAULT_THROTTLE_RATES": {
    "login": "5/min",
  }
}

from rest_framework.views import APIView

class LoginView(APIView):
    throttle_scope = "login"
```

* De scope staat **direct in de view**.
* De gedeelde throttle (`ScopedRateThrottle`) bepaalt of het een login‑scope is en haalt de rate uit de settings.
* Code is korter en policies zijn centraal beheerd.

---

## 3. Verschil 2: Wie garandeert de toepassing? – Standaardregistratie vs View‑specifieke installatie {#sec-693e9b27f525}

### Patroon B: Veel misvattingen {#sec-579edda7168e}

Het toevoegen van `ScopedRateThrottle` aan `DEFAULT_THROTTLE_CLASSES` heeft **geen effect** op views zonder `throttle_scope`. Dus je hoeft je geen zorgen te maken dat alle API‑punten ineens geblokkeerd worden.

### Patroon A: Sterke punten {#sec-1d7d8c13bc83}

Je kunt zonder globale instellingen een specifieke view een throttle toewijzen. Dit is handig als je de settings niet kunt aanpassen of alleen een bepaald app/endpoint wilt afdwingen.

---

## 4. Verschil 3: Schaalbaarheid – Wanneer A voordeliger wordt {#sec-76818ce0201b}

De twee patronen lijken gelijk voor één scope en één rate per view. Vanaf daar divergeren ze.

### 1) Meerdere throttles (burst + sustained) op één view {#sec-c0ea02305999}

DRF laat zien hoe je meerdere `UserRateThrottle`‑subclasses kunt gebruiken:

```python
class Burst(UserRateThrottle):
    scope = "burst"

class Sustained(UserRateThrottle):
    scope = "sustained"

class SearchView(APIView):
    throttle_classes = [Burst, Sustained]
```

Met alleen `ScopedRateThrottle` is het lastig om twee scopes op één view te hanteren; je hebt een subclass nodig (of een aangepaste implementatie).

### 2) Veranderen van de basis voor throttling {#sec-39de8e67072d}

`ScopedRateThrottle` werkt standaard op userID/IP. In de praktijk ontstaan vaak andere vereisten:

* Login: limiet op IP + gebruikersnaam (tegen account‑targeting).
* Organisatie/tenant: limiet op `tenant_id`.
* API‑sleutel: limiet op de sleutel zelf.

Dit vereist een aangepaste `get_cache_key()`‑implementatie, wat leidt tot een subclass (Patroon A). DRF moedigt ook custom throttles aan.

---

![Twee sleutels die een API‑verbinding openen](/media/editor_temp/6/e98f026a-a38e-43ca-8c86-fa7966dd3cdf.png)

## 5. Welke aanpak kiezen? {#sec-1cf080d47909}

### Voor de meeste “view‑specifieke rate limits” → Patroon B (ScopedRateThrottle) {#sec-924ae91c07d2}

* Minder code
* Policies centraal in settings
* Alleen `throttle_scope` in de view
* Views zonder scope worden niet beperkt

### Als een van de volgende geldt → Patroon A (subclass/aanpassing) {#sec-335f8d95a231}

* Meerdere limieten (burst + sustained) op één view
* Een custom basis (bijv. username+IP, tenant, API‑sleutel)
* Je kunt de globale settings niet aanpassen en wil een specifieke view afdwingen
* Je wilt de policy documenteren via de klassenaam

**Meer lezen:**

- [DRF Throttling volledig beheerst: configuratie, toepassing, custom‑gids](/ko/whitedec/2026/1/26/drf-throttling-complete-guide/)