Implementar a Bookings API com base na especificação openapi

Não quer configurar isso manualmente? Cole um link para esta página em uma sessão do Devin e peça para ele configurar tudo para você.

(Opcional) Analise seus padrões de API existentes

Se você não tiver certeza de como sua API Express está estruturada ou quais padrões deve usar como referência, use o Ask Devin para investigar primeiro:Você também pode usar o DeepWiki para explorar APIs open source com padrões semelhantes — por exemplo, pesquise por exemplos de Express + Prisma + Zod para ver como outros projetos estruturam seus route handlers e validações.Você pode iniciar uma sessão do Devin diretamente a partir do Ask Devin, e essa sessão vai aproveitar tudo o que ele aprendeu como contexto.

Conecte o Devin à sua especificação OpenAPI

Comece dizendo ao Devin onde está a especificação e qual recurso implementar. Devin lê todos os paths, schemas e definições de erro no YAML e, em seguida, cruza isso com suas rotas Express existentes para alinhar automaticamente às convenções.Aqui está um trecho do tipo de especificação com a qual o Devin trabalha — uma definição padrão OpenAPI 3.0 para um recurso de reservas:

# 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 segue os padrões do seu Express

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 também deriva esquemas Zod diretamente das definições de componentes do OpenAPI, para que a validação de requisições permaneça em sincronia com a especificação:

// src/api/v2/bookings/schemas.ts  (gerado pelo 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(),
});

Certifique-se de que a sua configuração de ambiente inclua a configuração do banco de dados de teste e todas as variáveis de ambiente necessárias para que o Devin possa executar o conjunto completo de testes localmente. Se sua API precisar de credenciais (URL do banco de dados, segredo JWT etc.), adicione-as como Secrets antes de iniciar a sessão — ou forneça-as durante a sessão via chat.

Devin entrega um PR testado

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 executa a suíte do Supertest antes de abrir o 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)

Itere sobre o que a especificação não cobre

A especificação OpenAPI define o contrato, mas raramente captura regras de negócio, lógica de autorização ou requisitos de desempenho. Use prompts de acompanhamento para preencher essas lacunas:

Revise o PR com o Devin Review

Quando o Devin abrir um PR, use o Devin Review para revisar a implementação. O Devin Review pode detectar problemas como falta de tratamento de erros, formatos de resposta inconsistentes ou endpoints que não seguem a especificação.Se o Devin Review sinalizar problemas, você pode usar o Autofix para que o Devin corrija automaticamente os problemas apontados — ele abre uma sessão de acompanhamento, aplica as correções e envia um commit atualizado sem que você precise descrever cada alteração manualmente.