手動でのセットアップを省略したい場合は、このページのリンクをDevinのセッションに貼り付けて、すべてのセットアップを依頼してください。 Express API の構成やどのパターンを参考にすればよいか分からない場合は、まず [Ask Devin](https://app.devin.ai/search?utm_source=docs\&utm_medium=use-case-gallery) を使って調査してください: ```txt Express API パターンの調査 theme={null} 私たちの Express API がどのように構成されているかを教えてください: 1. src/api/v2/ 配下のフォルダ構成はどうなっていますか？ 2. ルートハンドラー、コントローラー、サービスはどのように連携していますか？ 3. 認証とバリデーションにはどのミドルウェアを使っていますか？ 4. エラーレスポンスはどのような形式ですか？ 5. テストセットアップ（Supertest、テスト DB 設定）はどのようになっていますか？ ``` [DeepWiki](https://deepwiki.com) を使って、類似パターンを持つオープンソース API を調査することもできます。たとえば、Express + Prisma + Zod のサンプルを検索して、他のプロジェクトがルートハンドラーやバリデーションをどのように構成しているかを確認できます。 Ask Devin から直接 Devin セッションを開始でき、そのセッションでは Ask Devin で得られた内容がそのままコンテキストとして引き継がれます。まず、仕様がどこにあり、どのリソースを実装すべきかをDevinに伝えます。DevinはYAML内のすべてのパス、スキーマ、エラー定義を読み取り、既存のExpressルートと突き合わせて、自動的に既存の規約に沿うようにします。 Devinが扱う仕様の一例を以下に示します。これは、bookingsリソース向けの標準的なOpenAPI 3.0仕様です。 ```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 Implement bookings API from OpenAPI spec theme={null} /api/v2/bookings 用に openapi/bookings-v2.yaml で定義されているエンドポイントを実装してください。この仕様では次のエンドポイントが定義されています: - GET /api/v2/bookings (ページネーション付き一覧 + 日付範囲フィルター) - POST /api/v2/bookings (作成) - GET /api/v2/bookings/:id - PATCH /api/v2/bookings/:id (部分更新) - DELETE /api/v2/bookings/:id (ソフトデリート) - POST /api/v2/bookings/:id/confirm - POST /api/v2/bookings/:id/cancel 既存の Express + Prisma スタックを使用してください。ルート構造、エラー処理、ミドルウェアについては src/api/v2/users/ のパターンに従ってください。 OpenAPI の request/response 定義から Zod スキーマを導出してください。 ## 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(), }); ``` [環境設定](/ja/onboard-devin/environment)にテスト用データベースの設定と必要な環境変数を含めておき、Devin がローカルでテストスイート全体を実行できるようにしてください。API に認証情報 (database URL、JWT secret など) が必要な場合は、セッションを開始する前にそれらを[Secrets](/ja/product-guides/secrets)として登録するか、セッション中にチャットで渡してください。 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 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) ``` OpenAPI 仕様はコントラクトを定義しますが、ビジネスルール、認可ロジック、またはパフォーマンス要件を捉えることはほとんどありません。フォローアッププロンプトを使用してギャップを埋めましょう： ```txt Add authorization rules theme={null} Only the booking creator or an admin should be able to PATCH or DELETE a booking. The confirm and cancel endpoints should also require the organizer role. Use our existing role-checking middleware from src/middleware/authorize.ts. ``` ```txt Add rate limiting and caching theme={null} Add rate limiting to POST /api/v2/bookings (20 per minute per user). Cache GET /api/v2/bookings responses in Redis with a 30-second TTL, invalidated on any write operation. ``` Devin が PR を作成したら、実装内容をレビューするために [Devin Review](https://app.devin.ai/review?utm_source=docs\&utm_medium=use-case-gallery) を使用します。Devin Review は、エラー処理の抜けやレスポンス形式の不整合、仕様と一致していないエンドポイントなどの問題を検出できます。 Devin Review が問題を検出した場合は、**Autofix** を使って Devin に自動的に修正させることができます。Autofix はフォローアップセッションを開き、修正を適用し、各変更点を手動で説明することなく更新されたコミットをプッシュします。

{title}