Einführung
Eine Support-API muss offene Tickets finden und einzelne Datensätze sicher erstellen, aktualisieren und löschen. Sie verbinden einen Worker mit D1, implementieren parametrisierten SQL-Zugriff und testen, wie die API mit fehlenden Datensätzen und ungültigen Eingaben umgeht.
Der HTTP-Router ist vorgegeben. Ihre Hauptaufgabe besteht daher in der Datenbankintegration. Dieses unabhängige Lab verwendet einen temporären Worker und eine D1-Datenbank sowie separate lokale Daten.
Verwenden Sie Ihr eigenes Lernkonto und eine neue VM. Die Einrichtung installiert zunächst Node.js 22.22.0 und führt anschließend npm install für das projektlokale Wrangler 4.131.1 sowie alle Abhängigkeiten für die Bewertung unter /home/labex/project/ticket-database aus. Die direkten Abhängigkeitsversionen sind festgelegt; bei der Installation wird eine eigene Lockdatei erstellt. Während der Einrichtung werden weder eine Cloud-Anmeldung noch bewertete Datenbankaktionen ausgeführt. Installieren Sie auf einem persönlichen Rechner dieselbe Wrangler-Version mit npm install --save-dev wrangler@4.131.1 in Ihrem Projekt.
Diese Übung verwendet kleine synthetische Datensätze innerhalb der kostenlosen D1-Kontingente. Vorhandene Nutzung des Kontos wird auf diese Kontingente angerechnet. Eine gekaufte Domain ist nicht erforderlich. Behalten Sie diese VM, bis sowohl die Ressourcenlöschung als auch die Abmeldung überprüft wurden.
Diese VM autorisieren und das Konto auswählen
In diesem Schritt verbinden Sie dieses neue Terminal mit Ihrem eigenen Lernkonto. Eine Anmeldung im Dashboard allein autorisiert die VM nicht. Die D1-Berechtigung erlaubt das Erstellen, Ändern und Löschen von Datenbanken. Die Workers-Berechtigung erlaubt Deployments. Die KV-Berechtigung unterstützt das Auflisten von Ressourcen bei der Wrangler-Bereinigung. Prüfen Sie die tatsächliche Einwilligungsseite einschließlich „Background Access“, bevor Sie die Autorisierung bestätigen.
Öffnen Sie das vorbereitete Projekt und prüfen Sie die festgelegte CLI-Version:
cd /home/labex/project/ticket-database
npx wrangler --version
Erwartet wird 4.131.1. Starten Sie die Geräteautorisierung. --device zeigt einen Browsercode an, und --browser=false überlässt Ihnen die Wahl, wie Sie den Browser öffnen:
npx wrangler login --device --browser=false --scopes account:read user:read d1:write workers_scripts:write workers_kv:write
Öffnen Sie die angezeigte URL im Browser, geben Sie den aktuellen Code ein, bestätigen Sie Ihr Lernkonto und die Berechtigungen und erteilen Sie die Autorisierung. Warten Sie, bis das Terminal den Erfolg bestätigt. Fügen Sie niemals Passwörter oder Tokens in Projektdateien ein.
npx wrangler whoami --json
Prüfen Sie loggedIn: true. Lesen Sie anschließend den Kontonamen name und die Konto-ID id, auch wenn nur ein Konto aufgeführt ist. Kopieren Sie die gewünschte ID in die folgende Konfiguration. Die folgende Shell-Variable verwendet 6 zufällige Bytes, also 12 Hexadezimalzeichen, um Kollisionen mit anderen Lernenden zu vermeiden. Ein Here-Dokument schreibt den JSON-Inhalt zwischen die beiden Zeilen mit JSON; $RUN wird darin erweitert.
Der umgekehrte Schrägstrich vor $schema erhält diesen JSON-Schlüssel unverändert; $RUN wird weiterhin durch den eindeutigen Namen dieses Durchlaufs ersetzt.
RUN=labex-c04-d02-$(openssl rand -hex 6)
cat > wrangler.jsonc <<JSON
{
"\$schema": "./node_modules/wrangler/config-schema.json",
"name": "$RUN",
"account_id": "YOUR_ACCOUNT_ID",
"main": "src/index.js",
"compatibility_date": "2026-09-15",
"workers_dev": true,
"preview_urls": false
}
JSON
Ersetzen Sie YOUR_ACCOUNT_ID, bevor Sie den Block ausführen. Lassen Sie dieses Terminal geöffnet, damit RUN verfügbar bleibt. name identifiziert diesen Durchlauf; account_id legt das Konto für Cloud-Aktionen fest. Die Datei ist gewöhnliches JSON und damit auch gültiges JSONC. Durch das Schreiben der Datei wird kein Worker deployed.
Unabhängige lokale und entfernte Daten vorbereiten
In diesem Schritt erstellen Sie die D1-Verbindung und füllen die bekannte Ticket-Tabelle mit Startdaten. Die Einrichtung stellt das HTTP-Routing und die Eingabevalidierung in src/index.js bereit. Die fehlenden Speicherfunktionen befinden sich in src/store.js. Dadurch konzentriert sich Ihre Arbeit auf den SQL-Zugriff.
Erstellen Sie eine temporäre Cloud-Datenbank. --binding DB gibt dem Anwendungscode einen kurzen Namen, --update-config speichert den tatsächlichen Namen und die UUID in wrangler.jsonc, und --use-remote=false hält die Entwicklung lokal:
npx wrangler d1 create "$RUN-db" --binding DB --update-config --use-remote=false
Lesen Sie den erstellten Namen und die ID und prüfen Sie anschließend die gespeicherte Bindung:
cat wrangler.jsonc
Der Eintrag DB muss die Datenbank dieses Durchlaufs bezeichnen. Eine Bindung ist eine konfigurierte Verbindung zwischen Code und einer Ressource. Ihre UUID identifiziert die Cloud-Datenbank, während --local eine separate SQLite-Datenbank in dieser VM verwendet. Geben Sie bei SQL-Befehlen immer entweder --local oder --remote an.
cat schema.sql
npx wrangler d1 execute DB --local --file schema.sql
npx wrangler d1 execute DB --remote --file schema.sql
Beide Ziele enthalten nun dieselben zwei Starttickets. DB ist der Name, den der bereitgestellte Handler als env.DB erhält. Er muss mit der Bindung in der Konfiguration übereinstimmen.
Parametrisierte CRUD-Funktionen implementieren
In diesem Schritt implementieren Sie CRUD: create, read, update und delete, also Erstellen, Lesen, Aktualisieren und Löschen. Eine vorbereitete Anweisung hält die SQL-Struktur von den Eingabedaten getrennt. Jedes ? ist ein Parameterplatzhalter; .bind(...) liefert die Werte in der angegebenen Reihenfolge. Fügen Sie Benutzereingaben niemals direkt in SQL ein, auch wenn sie harmlos aussehen.
WHERE schränkt die betroffenen Datensätze ein. .all() gibt ein Ergebnisobjekt zurück, dessen Feld results das Zeilen-Array enthält. .first() gibt eine Zeile oder null zurück. Die SQLite-Klausel RETURNING liefert die geänderte Zeile zurück, ohne dass eine separate Abfrage erforderlich ist. Beim Löschen stellt .run() meta.changes bereit. Dieser Wert zeigt dem Router, ob der Datensatz tatsächlich vorhanden war.
Schreiben Sie das Speichermodul:
cat > src/store.js <<'JS'
export async function list(db, status) {
const query = status === null
? db.prepare('SELECT id, subject, status, source FROM tickets ORDER BY id')
: db.prepare('SELECT id, subject, status, source FROM tickets WHERE status = ? ORDER BY id').bind(status);
const { results } = await query.all();
return results;
}
export async function get(db, id) {
return db.prepare('SELECT id, subject, status, source FROM tickets WHERE id = ?').bind(id).first();
}
export async function create(db, subject) {
return db.prepare("INSERT INTO tickets (subject, source) VALUES (?, 'api') RETURNING id, subject, status, source").bind(subject).first();
}
export async function update(db, id, status) {
return db.prepare('UPDATE tickets SET status = ? WHERE id = ? RETURNING id, subject, status, source').bind(status, id).first();
}
export async function remove(db, id) {
const result = await db.prepare('DELETE FROM tickets WHERE id = ?').bind(id).run();
return result.meta.changes === 1;
}
JS
Lesen Sie src/index.js, um zu sehen, wie das vorgegebene Routing diese Funktionen verwendet. Fehlende Datensätze werden zu einem kontrollierten 404, fehlerhafte Eingaben zu einem 400. Ein abgefangener Datenbankfehler wird als 503 zurückgegeben, ohne SQL-Interna offenzulegen.
Starten Sie den lokalen Server als Hintergrundprozess, damit das Terminal verfügbar bleibt:
npx wrangler dev --ip 0.0.0.0 > dev.log 2>&1 &
Lesen Sie das Startprotokoll und warten Sie auf die Meldung, dass der Server auf Verbindungen wartet:
cat dev.log
curl -i http://localhost:8787/tickets?status=open
Erwartet werden HTTP 200 und ausschließlich Ticket 1. Der Server verwendet die lokale Datenbank. Merken Sie sich die Jobnummer, die das Terminal für die spätere Bereinigung ausgibt.
Schreibvorgänge und abgelehnte Eingaben lokal testen
In diesem Schritt testen Sie mehr als nur erfolgreiche Lesevorgänge. curl -i zeigt den HTTP-Status und die Header. -H setzt den JSON-Inhaltstyp, und -d sendet standardmäßig bei POST einen Body.
Erstellen Sie einen Betreff mit SQL-ähnlichen Sonderzeichen:
curl -i http://localhost:8787/tickets -H 'Content-Type: application/json' -d "{\"subject\":\"Printer ' OR 1=1 --\"}"
Erwartet werden 201 und ein Betreff, der unverändert als Daten gespeichert wurde. Kopieren Sie die zurückgegebene numerische id in TICKET_ID. Gehen Sie nicht davon aus, dass IDs nach wiederholten Tests gleich bleiben:
TICKET_ID=YOUR_RETURNED_ID
curl -i http://localhost:8787/tickets/$TICKET_ID
curl -i -X PATCH http://localhost:8787/tickets/$TICKET_ID -H 'Content-Type: application/json' -d '{"status":"closed"}'
curl -i -X DELETE http://localhost:8787/tickets/$TICKET_ID
curl -i http://localhost:8787/tickets/$TICKET_ID
Erwartet werden zuerst eine 200-Antwort beim Lesen, eine 200-Antwort beim Aktualisieren mit closed, eine 204-Antwort beim Löschen ohne Body und anschließend 404 mit {"error":"not_found"}. Die beiden ursprünglichen Tickets müssen erhalten bleiben.
Senden Sie ungültiges JSON und einen ungültigen Status:
curl -i http://localhost:8787/tickets -H 'Content-Type: application/json' -d '{'
curl -i -X PATCH http://localhost:8787/tickets/1 -H 'Content-Type: application/json' -d '{"status":"lost"}'
Erwartet werden jeweils HTTP 400 mit invalid_json beziehungsweise invalid_status. Die SQL-Parametrisierung verhindert, dass Eingaben zu SQL werden. Die Anwendungsvalidierung lehnt Werte ab, die außerhalb der Geschäftsregeln liegen. Diese beiden Mechanismen lösen unterschiedliche Probleme.
Die gebundene Datenbank deployen und testen
In diesem Schritt veröffentlichen Sie den Handler und seine D1-Bindung. Die entfernte Datenbank ist bereits mit Startdaten gefüllt. Beim Deployment werden lokale Zeilen nicht kopiert.
npx wrangler deploy
Kopieren Sie die beim Deployment ausgegebene tatsächliche https://...workers.dev-URL in eine Shell-Variable. Diese synthetische API ist nur für diesen Test vorgesehen. Entfernen Sie sie anschließend:
URL='YOUR_DEPLOYED_HTTPS_URL'
curl -i "$URL/tickets?status=open"
Erwartet werden 200 und Ticket 1. Wenn ein frisches Deployment vorübergehend einen Plattformfehler zurückgibt, warten Sie einige Sekunden und wiederholen Sie diese Abfrage bis zu einer Minute lang. Fahren Sie erst fort, wenn sowohl Status als auch JSON übereinstimmen. Anhaltende Fehler müssen untersucht werden.
Wiederholen Sie die CRUD-Tests gegen die entfernte API und verwenden Sie die dort zurückgegebene ID:
curl -i "$URL/tickets" -H 'Content-Type: application/json' -d '{"subject":"Remote test"}'
TICKET_ID=YOUR_RETURNED_ID
curl -i -X PATCH "$URL/tickets/$TICKET_ID" -H 'Content-Type: application/json' -d '{"status":"closed"}'
curl -i -X DELETE "$URL/tickets/$TICKET_ID"
curl -i "$URL/tickets/$TICKET_ID"
curl -i "$URL/tickets"
Erwartet werden 201, 200, 204, 404 und anschließend die beiden unveränderten Starttickets. Öffnen Sie im Dashboard genau diesen Worker und die Ansicht „Bindings“. Bestätigen Sie, dass DB auf Ihre Datenbank verweist. Folgen Sie dem Datenbanklink für eine schreibgeschützte Prüfung. Eine gespeicherte lokale Bindung ist kein Beleg dafür, dass die bereitgestellte Verbindung korrekt ist.
Dieses Beispiel zeigt den bereitgestellten Worker, der über DB mit seiner D1-Datenbank verbunden ist. Das zufällige Suffix kennzeichnet diesen Beispieldurchlauf; deine Namen werden abweichen. Der Link Value in der Tabelle öffnet die Datenbank, die durch die bereitgestellte Bindung ausgewählt wurde.
Die temporären Ressourcen löschen
In diesem Schritt entfernen Sie nur die Ressourcen dieses Labs, solange die VM noch autorisiert ist. Führen Sie zuerst alle funktionalen Prüfungen vollständig durch. Behalten Sie die Konfiguration, bis die Löschung überprüft wurde.
npx wrangler delete
Bestätigen Sie, dass nur der Workername aus der Konfiguration dieses Durchlaufs gelöscht wird.
npx wrangler d1 delete DB
Prüfen Sie die Eingabeaufforderung und bestätigen Sie, dass nur die Datenbank dieses Durchlaufs betroffen ist. Listen Sie anschließend die Datenbanken auf:
npx wrangler d1 list --json
Der von Ihnen notierte Datenbankname und die UUID müssen in einer erfolgreichen Antwort fehlen. Andere Ressourcen dürfen weiterhin vorhanden sein. Ein Authentifizierungs- oder Netzwerkfehler ist nicht aussagekräftig: Beheben Sie den Zugriff und wiederholen Sie die Abfrage, bevor Sie fortfahren. Führen Sie die Überprüfung dieses Schritts aus, solange Sie noch angemeldet sind.
Beenden Sie auch den lokalen Entwicklungsprozess. Listen Sie die Jobs auf und beenden Sie ausschließlich den von Ihnen gestarteten wrangler dev-Job. Ersetzen Sie %1, falls die Jobnummer abweicht:
jobs
kill %1
Die Autorisierung dieser VM beenden
In diesem Schritt beenden Sie die Autorisierung erst, nachdem die unabhängige Löschprüfung erfolgreich war. Durch die Abmeldung wird die auf dieser VM gespeicherte Wrangler-Autorisierung entfernt. Das bloße Schließen einer VM ist keine Cloud-Bereinigung.
npx wrangler logout
npx wrangler whoami --json
Erwartet wird loggedIn: false. Diese nicht authentifizierte Abfrage kann mit einem Fehlercode beendet werden. Das ist nur dann erwartungsgemäß, wenn die strukturierte Antwort ausdrücklich angibt, dass Sie abgemeldet sind. Schließen Sie zunächst die Überprüfung ab und beenden Sie anschließend die Lab-Umgebung.
Zusammenfassung
Sie haben gelernt, eine Ticketsuche zu einem Worker hinzuzufügen. Sie haben die beobachtbaren Datenbankergebnisse geprüft, das ausgewählte Konto und den lokalen Zustand explizit gehalten und die temporären Ressourcen vor der Abmeldung entfernt.
