Bookings API aus OpenAPI-Spezifikation implementieren

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.

(Optional) Analysieren Sie Ihre bestehenden API-Patterns

Wenn du dir nicht sicher bist, wie deine Express-API aufgebaut ist oder welche Patterns du als Referenz heranziehen kannst, nutze Ask Devin, um das zunächst zu analysieren:Du kannst auch DeepWiki 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.

Verknüpfen Sie Devin mit Ihrer OpenAPI-Spezifikation

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:

# 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

If your spec isn’t checked into the repo yet, paste it directly into the session or attach the YAML/JSON file when starting.

Devin orientiert sich an Ihren Express-Patterns

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:

// 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:

// 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 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 before starting the session — or provide them during the session via chat.

Devin erstellt einen getesteten Pull Request (PR)

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)

Arbeiten Sie alles aus, was die Spezifikation nicht abdeckt

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:

Prüfen Sie den PR mit Devin Review

Sobald Devin den PR erstellt, kannst du Devin Review 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.