Viele APIs paginieren nicht mit einer Seitennummer oder einem Offset. Stattdessen liefert die erste Antwort einen Token für den nächsten Abschnitt. Oracle APEX 24.2 unterstützt dieses Muster jetzt in Simple HTTP REST Data Sources deklarativ. Das reduziert individuellen PL/SQL- und JavaScript-Code und sorgt dafür, dass Reports, Cards oder andere APEX-Komponenten die Seitennavigation einheitlich behandeln.
1. API-Vertrag zuerst prüfen
Bevor die REST Data Source angelegt wird, sollte die API-Dokumentation drei Dinge eindeutig beschreiben: den Parameter für die Seitengröße, den Parameter für den Folgetoken und das Feld, in dem die Antwort den nächsten Token zurückgibt. Typisch ist zum Beispiel ein Aufruf wie:
GET /orders?limit=100&token=ApEx=Die Namen sind nicht standardisiert. Ein Dienst kann statt limit auch page_size verwenden und den Token unter next_cursor, nextToken oder in einem verschachtelten Objekt zurückgeben. Entscheidend ist die exakte Abstimmung mit dem Response-Schema.
2. REST Data Source konfigurieren
Legen Sie die Quelle unter Shared Components als Simple HTTP REST Data Source an und wählen Sie bei Pagination den Typ Page Size and Page Token. Hinterlegen Sie anschließend die API-spezifischen Parameter und lassen Sie das Response-Format analysieren. Das Data Profile muss die Nutzdaten und das Token-Feld korrekt abbilden.
Für die erste Umsetzung empfiehlt sich eine kleine Seitengröße. So lassen sich Antwortzeiten, Rate Limits und die tatsächliche Struktur der nächsten Seite leichter prüfen. Die maximale Größe sollte vom API-Anbieter übernommen werden, nicht aus der APEX-Region erraten werden.
3. Data Profile und Komponenten testen
Prüfen Sie die Quelle zunächst mit einer einzelnen GET-Operation. Kontrollieren Sie dabei:
- Werden Datensätze aus der ersten Seite erkannt?
- Wird der nächste Token aus der Antwort gelesen?
- Wird der Token unverändert an die Folgeanfrage übergeben?
- Was passiert, wenn kein Token mehr vorhanden ist?
Erst wenn diese Fälle funktionieren, sollte die Quelle als Basis für eine Cards-, Report- oder Chart-Region verwendet werden. Bei Fehlern ist die Network-Antwort des Dienstes meist aussagekräftiger als die sichtbare APEX-Fehlermeldung.
4. Caching, Limits und Fehlerfälle
Tokenbasierte APIs können Tokens an eine Session, einen Filterzustand oder eine kurze Gültigkeitsdauer binden. Seien Sie deshalb vorsichtig mit serverseitigem Caching: Ein gespeicherter Response darf nicht dazu führen, dass ein Token in einem unpassenden Kontext wiederverwendet wird. Prüfen Sie die Cache-Invalidierung passend zur Fachlichkeit und zum API-Vertrag.
Dokumentieren Sie außerdem Rate Limits, Authentifizierung und das Verhalten bei abgelaufenen Tokens. Ein klarer leerer Zustand und eine verständliche Fehlermeldung sind besser als eine scheinbar leere Region. Für teure oder häufig genutzte APIs kann eine lokale Synchronisation in eine Tabelle sinnvoller sein als jeder Laufzeitabruf.
Praktische Checkliste
- Token-Feld und Seitengrößenparameter aus der API-Dokumentation bestätigen.
- Pagination Type „Page Size and Page Token“ wählen.
- Response Data Profile inklusive nächstem Token prüfen.
- Erste Seite, Folgeseite und letzte Seite testen.
- Cache, Rate Limits und abgelaufene Tokens dokumentieren.
Fazit
Mit der tokenbasierten Pagination in APEX 24.2 lassen sich moderne REST-APIs deutlich sauberer anbinden. Die deklarative Konfiguration nimmt viel Integrationscode ab, ersetzt aber nicht das Verständnis des API-Vertrags. Wer Token-Lebensdauer, Data Profile, Limits und Fehlerzustände von Anfang an testet, erhält eine robuste Datenquelle für mehrere APEX-Komponenten.
Weiterführend: REST-Verbesserungen in APEX 24.2 und die Dokumentation zum Erstellen einer REST Data Source.