Möchten Sie das nicht manuell einrichten? Fügen Sie einen Link zu dieser Seite in eine Devin-Sitzung ein und bitten Sie Devin, alles für Sie einzurichten. Wenn du dir nicht sicher bist, wie deine Express-API aufgebaut ist oder welche Patterns du als Referenz heranziehen kannst, nutze [Ask Devin](https://app.devin.ai/search?utm_source=docs\&utm_medium=use-case-gallery), um das zunächst zu analysieren: ```txt Research our Express API patterns theme={null} Show me how our Express API is structured: 1. What's the folder layout under src/api/v2/? 2. How do route handlers, controllers, and services interact? 3. Which middleware do we use for auth and validation? 4. How are error responses formatted? 5. What does our test setup look like (Supertest, test DB config)? ``` Du kannst auch [DeepWiki](https://deepwiki.com) nutzen, um Open-Source-APIs mit ähnlichen Patterns zu erkunden – suche dort zum Beispiel nach Express- + Prisma- + Zod-Beispielen, um zu sehen, wie andere Projekte ihre Route-Handler und Validierung strukturieren. Du kannst eine Devin-Session direkt aus Ask Devin starten, und Devin übernimmt dabei den gesamten zuvor gewonnenen Kontext. Beginnen Sie damit, Devin mitzuteilen, wo die Spezifikation liegt und welche Ressource implementiert werden soll. Devin liest jeden Pfad, jedes Schema und jede Fehlerdefinition in der YAML-Spezifikation und gleicht sie dann automatisch mit Ihren bestehenden Express-Routen ab, um Ihre bestehenden Konventionen einzuhalten. Hier ist ein Auszug aus der Art von Spezifikation, mit der Devin arbeitet — eine Standard-OpenAPI-3.0-Definition für eine Buchungsressource: ```yaml theme={null} # openapi/bookings-v2.yaml (excerpt) openapi: "3.0.3" info: title: Bookings API version: "2.0.0" paths: /api/v2/bookings: get: summary: List bookings parameters: - name: page in: query schema: { type: integer, default: 1 } - name: startDate in: query schema: { type: string, format: date } - name: endDate in: query schema: { type: string, format: date } responses: "200": description: Paginated list of bookings content: application/json: schema: $ref: "#/components/schemas/BookingListResponse" post: summary: Create a booking requestBody: required: true content: application/json: schema: $ref: "#/components/schemas/CreateBookingInput" responses: "201": description: Booking created "409": description: Time slot conflict /api/v2/bookings/{id}/confirm: post: summary: Confirm a booking responses: "200": description: Booking confirmed "422": description: Booking already cancelled components: schemas: CreateBookingInput: type: object required: [title, startTime, endTime, roomId] properties: title: type: string maxLength: 200 startTime: type: string format: date-time endTime: type: string format: date-time roomId: type: string format: uuid ``` ```txt Implementiere die Buchungs-API anhand der OpenAPI-Spezifikation theme={null} Implementiere die in openapi/bookings-v2.yaml definierten Endpunkte für /api/v2/bookings. Die Spezifikation definiert: - GET /api/v2/bookings (Liste mit Paginierung + Datumsbereichsfilter) - POST /api/v2/bookings (Erstellen) - GET /api/v2/bookings/:id - PATCH /api/v2/bookings/:id (Teilaktualisierung) - DELETE /api/v2/bookings/:id (Soft Delete) - POST /api/v2/bookings/:id/confirm - POST /api/v2/bookings/:id/cancel Verwende unseren bestehenden Express- + Prisma-Stack. Folge den Mustern in src/api/v2/users/ für Routenstruktur, Fehlerbehandlung und Middleware. Leite Zod-Schemas aus den OpenAPI-Request-/Response-Definitionen ab. ## Testing & verification - Write integration tests with Supertest for every endpoint - Cover success cases, validation errors, auth failures, and business logic edge cases (e.g., overlapping time slots) - Run all tests and verify every endpoint works correctly - If anything fails — test failures, runtime errors, missing middleware — debug and fix it. Keep iterating until all tests pass. - Do not open a PR until everything works end-to-end ``` If your spec isn't checked into the repo yet, paste it directly into the session or attach the YAML/JSON file when starting. The single most impactful thing you can do is reference a well-implemented resource in your codebase. Devin studies that code and replicates the folder structure, naming conventions, middleware chain, and error handling — so the new endpoints look like they were written by the same developer. For example, Devin reads `src/api/v2/users/router.ts` and produces a matching bookings router: ```typescript theme={null} // src/api/v2/bookings/router.ts (generated by Devin) import { Router } from "express"; import { authenticate } from "@/middleware/auth"; import { validate } from "@/middleware/validate"; import { BookingsController } from "./controller"; import { createBookingSchema, updateBookingSchema, listBookingsQuerySchema, } from "./schemas"; const router = Router(); const ctrl = new BookingsController(); router.use(authenticate); router.get("/", validate({ query: listBookingsQuerySchema }), ctrl.list); router.post("/", validate({ body: createBookingSchema }), ctrl.create); router.get("/:id", ctrl.getById); router.patch("/:id", validate({ body: updateBookingSchema }), ctrl.update); router.delete("/:id", ctrl.softDelete); router.post("/:id/confirm", ctrl.confirm); router.post("/:id/cancel", ctrl.cancel); export default router; ``` Devin also derives Zod schemas directly from the OpenAPI component definitions, so request validation stays in sync with the spec: ```typescript theme={null} // src/api/v2/bookings/schemas.ts (generated by Devin) import { z } from "zod"; export const createBookingSchema = z.object({ title: z.string().max(200), startTime: z.string().datetime(), endTime: z.string().datetime(), roomId: z.string().uuid(), notes: z.string().max(1000).optional(), }); export const updateBookingSchema = createBookingSchema.partial(); export const listBookingsQuerySchema = z.object({ page: z.coerce.number().int().positive().default(1), limit: z.coerce.number().int().min(1).max(100).default(20), startDate: z.string().date().optional(), endDate: z.string().date().optional(), }); ``` Stellen Sie sicher, dass Ihre [Umgebungskonfiguration](/de/onboard-devin/environment) die Konfiguration der Testdatenbank und alle erforderlichen Umgebungsvariablen enthält, damit Devin die vollständige Test-Suite lokal ausführen kann. If your API needs credentials (database URL, JWT secret, etc.), add them as [Secrets](/de/product-guides/secrets) before starting the session — or provide them during the session via chat. Devin reads the spec, studies your existing code, and implements each endpoint to match both the OpenAPI contract and your Express codebase conventions. Here's what a typical PR looks like: ``` feat: Implement /api/v2/bookings endpoints from OpenAPI spec src/api/v2/bookings/ router.ts (Express route definitions + middleware) controller.ts (request handling) service.ts (business logic) repository.ts (Prisma queries) schemas.ts (Zod validation from spec) prisma/migrations/ 20260219_add_bookings/ (migration) src/__tests__/ bookings.integration.ts (Supertest tests) ``` Devin führt die Supertest-Suite aus, bevor Devin den Pull Request (PR) öffnet: ``` /api/v2/bookings GET / passes returns paginated bookings (42ms) passes filters by date range (38ms) passes returns 401 without auth (8ms) POST / passes creates booking with valid data (61ms) passes returns 400 for missing required fields (12ms) passes returns 409 for overlapping time slot (29ms) PATCH /:id passes updates booking fields (22ms) passes returns 404 for non-existent booking (9ms) POST /:id/confirm passes transitions status to confirmed (18ms) passes returns 422 for already-cancelled booking (11ms) 16 passing (412ms) ``` Die OpenAPI-Spezifikation definiert den Vertrag, erfasst jedoch selten Geschäftsregeln, Berechtigungslogik oder Leistungsanforderungen. Verwenden Sie nachfolgende Prompts, um diese Lücken zu schließen: ```txt Fügen Sie Autorisierungsregeln hinzu theme={null} Nur der Ersteller der Buchung oder ein Admin sollte eine Buchung PATCH oder DELETE dürfen. Die Endpunkte confirm und cancel sollten außerdem die Rolle organizer erfordern. Verwenden Sie unsere bestehende Middleware zur Rollenprüfung aus src/middleware/authorize.ts. ``` ```txt Fügen Sie Rate Limiting und Caching hinzu theme={null} Fügen Sie Rate Limiting für POST /api/v2/bookings hinzu (20 pro Benutzer und Minute). Cachen Sie GET /api/v2/bookings-Antworten in Redis mit einer TTL von 30 Sekunden, deren Cache bei jeder Schreiboperation ungültig gemacht wird. ``` Sobald Devin den PR erstellt, kannst du [Devin Review](https://app.devin.ai/review?utm_source=docs\&utm_medium=use-case-gallery) verwenden, um die Implementierung zu überprüfen. Devin Review kann Probleme wie fehlende Fehlerbehandlung, inkonsistente Antwortformate oder Endpunkte erkennen, die nicht der Spezifikation entsprechen. Wenn Devin Review Probleme markiert, kannst du **Autofix** verwenden, damit Devin die markierten Probleme automatisch behebt — es öffnet eine Folgesitzung, wendet die Korrekturen an und pusht einen aktualisierten Commit, ohne dass du jede Änderung manuell beschreiben musst.

{title}