Skip to main content

Implémenter l’API Bookings à partir de la spécification OpenAPI

Confie à Devin une spécification YAML et obtiens des gestionnaires de routes Express entièrement implémentés, des modèles Prisma, une validation Zod et des tests d’intégration Supertest — tous alignés sur les conventions existantes de ta base de code.
AuthorCognition
CategoryDéveloppement de fonctionnalités
1

(Facultatif) Étudiez vos modèles d’API existants

Si vous ne savez pas comment votre API Express est structurée ni à quels patterns vous référer, utilisez Ask Devin pour commencer votre analyse :Vous pouvez aussi utiliser DeepWiki pour explorer des API open source présentant des patterns similaires — par exemple, recherchez des exemples Express + Prisma + Zod pour voir comment d’autres projets structurent leurs gestionnaires de routes et leur validation.Vous pouvez démarrer une session Devin directement depuis Ask Devin, et tout ce qu’il a appris sera conservé comme contexte.
2

Pointez Devin vers votre spécification OpenAPI

Commencez par indiquer à Devin où se trouve la spécification et quelle ressource implémenter. Devin lit chaque chemin, schéma et définition d’erreur dans le YAML, puis les compare à vos routes Express existantes afin d’aligner automatiquement les conventions.Voici un extrait du type de spécification que Devin utilise — une définition standard OpenAPI 3.0 pour une ressource de réservations :
# openapi/bookings-v2.yaml (extrait)
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
Si votre spécification n’est pas encore commit dans le dépôt, collez-la directement dans la session ou joignez le fichier YAML/JSON au démarrage.
3

Devin s’adapte à vos modèles Express

La chose la plus importante que vous puissiez faire est de fournir en référence, dans votre base de code, une ressource bien implémentée. Devin étudie ce code et reproduit la structure des dossiers, les conventions de nommage, la chaîne de middleware et la gestion des erreurs — de sorte que les nouveaux endpoints donnent l’impression d’avoir été écrits par le même développeur.Par exemple, Devin lit src/api/v2/users/router.ts et produit un routeur de réservations correspondant :
// src/api/v2/bookings/router.ts  (généré par 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 dérive également des schémas Zod directement à partir des définitions de composants OpenAPI, ainsi la validation des requêtes reste alignée sur la spécification :
// src/api/v2/bookings/schemas.ts  (généré par 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(),
});
Assurez-vous que la configuration du dépôt inclut la configuration de la base de données de test et toutes les variables d’environnement nécessaires afin que Devin puisse exécuter l’ensemble de la suite de tests en local. Si votre API a besoin d’identifiants (URL de base de données, secret JWT, etc.), ajoutez-les en tant que Secrets avant de lancer la session — ou fournissez-les pendant la session via le chat.
4

Devin fournit une PR testée

Devin lit la spécification, étudie votre code existant et implémente chaque endpoint de façon à respecter à la fois le contrat OpenAPI et les conventions de votre codebase Express. Voici à quoi ressemble généralement une pull request (PR) :
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 exécute la suite de tests Supertest avant d’ouvrir la pull request (PR) :
  /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)
5

Itérer sur les aspects non couverts par la spécification

La spécification OpenAPI définit le contrat mais capture rarement les règles métier, la logique d’autorisation ou les exigences de performance. Utilisez des prompts complémentaires pour combler ces lacunes :
6

Passez en revue la PR avec Devin Review

Une fois que Devin a ouvert la pull request (PR), utilisez Devin Review pour examiner l’implémentation. Devin Review peut détecter des problèmes comme l’absence de gestion des erreurs, des formats de réponse incohérents ou des endpoints qui ne respectent pas la spécification.Si Devin Review signale des problèmes, vous pouvez utiliser Autofix pour que Devin corrige automatiquement les problèmes signalés — il ouvre une session de suivi, applique les corrections et pousse un commit mis à jour sans que vous ayez à décrire chaque changement manuellement.