Vous ne souhaitez pas effectuer cette configuration manuellement ? Collez un lien vers cette page dans une session Devin et demandez-lui de tout configurer pour vous. Si vous ne savez pas comment votre API Express est structurée ni à quels patterns vous référer, utilisez [Ask Devin](https://app.devin.ai/search?utm_source=docs\&utm_medium=use-case-gallery) pour commencer votre analyse : ```txt Analyse nos patterns d'API Express theme={null} Montre-moi comment notre API Express est structurée : 1. Quelle est l'arborescence des dossiers sous src/api/v2/ ? 2. Comment les gestionnaires de routes, contrôleurs et services interagissent-ils ? 3. Quels middleware utilisons-nous pour l'authentification et la validation ? 4. Comment les réponses d'erreur sont-elles formatées ? 5. À quoi ressemble notre configuration de tests (Supertest, configuration de la base de données de test) ? ``` Vous pouvez aussi utiliser [DeepWiki](https://deepwiki.com) 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. 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 : ```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 Implémenter l'API de réservations à partir de la spécification OpenAPI theme={null} Implémentez les endpoints définis dans openapi/bookings-v2.yaml pour /api/v2/bookings. La spécification définit : - GET /api/v2/bookings (liste avec pagination + filtre par plage de dates) - POST /api/v2/bookings (création) - GET /api/v2/bookings/:id - PATCH /api/v2/bookings/:id (mise à jour partielle) - DELETE /api/v2/bookings/:id (suppression logique) - POST /api/v2/bookings/:id/confirm - POST /api/v2/bookings/:id/cancel Utilisez notre stack Express + Prisma existante. Suivez les modèles dans src/api/v2/users/ pour la structure des routes, la gestion des erreurs et le middleware. Déduisez les schémas Zod à partir des définitions de requêtes/réponses OpenAPI. ## 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 (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 de l’environnement](/fr/onboard-devin/environment) 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](/fr/product-guides/secrets) avant de lancer la session — ou fournissez-les pendant la session via le chat. Devin lit la spécification, étudie votre code existant et implémente chaque endpoint afin de respecter à la fois le contrat OpenAPI et les conventions de votre codebase Express. Voici à quoi ressemble une PR typique : ``` 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 runs the Supertest suite before opening the 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) ``` 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 : ```txt Add authorization rules theme={null} Seul le créateur de la réservation ou un administrateur doit pouvoir PATCH ou DELETE une réservation. Les endpoints confirm et cancel doivent également exiger le rôle d'organisateur. Utilisez notre middleware de vérification de rôle existant dans src/middleware/authorize.ts. ``` ```txt Add rate limiting and caching theme={null} Ajoutez une limitation de débit à POST /api/v2/bookings (20 par minute et par utilisateur). Mettez en cache les réponses GET /api/v2/bookings dans Redis avec un TTL de 30 secondes, invalidé à chaque opération d'écriture. ``` Une fois que Devin a ouvert la pull request (PR), utilisez [Devin Review](https://app.devin.ai/review?utm_source=docs\&utm_medium=use-case-gallery) 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.

{title}