Bruno có máy chủ giả lập không? (Và nên dùng gì thay thế)

Bruno là một API client mã nguồn mở, nhẹ và Git-native, phù hợp để quản lý collection bằng file văn bản thuần túy. Điểm hạn chế là Bruno không có mock server tích hợp: bạn có thể gửi request và viết test, nhưng không thể biến một endpoint đã lưu thành endpoint giả trả về response mẫu. Bài viết này hướng dẫn cách xử lý khoảng trống đó và cách tạo mock server trực tiếp từ OpenAPI spec.

Dùng thử Apidog hôm nay

Câu trả lời ngắn gọn: Bruno không có mock server built-in. Nếu muốn mock API, bạn cần dùng công cụ bên ngoài hoặc tự dựng một server nhỏ để trả về dữ liệu giả.

Tại sao bạn cần mock server

Mock server trả về response giống API thật cho các endpoint chưa được xây dựng, chưa ổn định hoặc khó tái tạo trong môi trường thật. Với developer, nó giúp bạn:

• Phát triển song song: Frontend/mobile có thể bắt đầu tích hợp dựa trên API contract trong khi backend vẫn đang triển khai.
• Kiểm thử error path: Chủ động trả về 429, 500, 503, header lỗi hoặc payload thiếu field.
• Demo và prototype: Chạy luồng sản phẩm mà không cần backend, database hoặc credential thật.
• CI ổn định hơn: Test suite không phụ thuộc vào staging server, rate limit hoặc dữ liệu thật.

Một số case nên mock thay vì chờ hệ thống thật phát sinh lỗi:

Kịch bản	Mock trả về gì	Vì sao khó kiểm thử nếu không mock
Đạt giới hạn tốc độ	429 + header Retry-After	Backend hiếm khi throttle đúng lúc bạn cần
Server lỗi	500 / 503	Không thể cố tình làm hỏng staging
Response chậm	Body bị delay	Khó tái tạo latency ổn định
Tập kết quả rỗng	200 với []	Phụ thuộc vào trạng thái dữ liệu
Payload lỗi	Body thiếu field bắt buộc	Backend thật thường chặn từ bước validation

Bruno có mock server không?

Không. Bruno tập trung vào:

• Gửi HTTP request
• Quản lý collection bằng file text
• Chạy assertion/test
• Làm việc tốt với Git

Bruno không có mock server gốc và không có setting nào để biến request đã lưu thành live stub endpoint. Đây là lựa chọn về phạm vi sản phẩm, không phải lỗi triển khai.

Trong thực tế, người dùng Bruno thường xử lý theo hai cách.

Cách 1: Dùng công cụ mock bên ngoài

Bạn có thể chạy một công cụ như Mockoon, WireMock, Prism hoặc json-server, sau đó trỏ Bruno đến URL mock đó.

Ví dụ flow:

Frontend / Bruno
      ↓
Mock server bên ngoài
      ↓
Response JSON giả

Cách này hoạt động, nhưng bạn phải duy trì thêm một nguồn định nghĩa response ngoài Bruno và ngoài OpenAPI spec.

Cách 2: Tự viết mock server

Ví dụ với Express:

import express from "express";

const app = express();

app.get("/users", (req, res) => {
  res.json([
    {
      id: 1,
      name: "Nguyen Van A",
      email: "[e-mail]"
    }
  ]);
});

app.get("/users/:id", (req, res) => {
  res.json({
    id: Number(req.params.id),
    name: "Nguyen Van A",
    email: "[e-mail]"
  });
});

app.listen(3000, () => {
  console.log("Mock server running at http://localhost:3000");
});

Sau đó trong Bruno, bạn gửi request đến:

http://localhost:3000/users

Cách này nhanh cho vài endpoint, nhưng sẽ tốn công khi API có nhiều route, nhiều schema và nhiều status code.

Chi phí của việc mock theo kiểu “đắp thêm”

Khi mock layer nằm ngoài API contract, chi phí bảo trì sẽ tăng dần:

• Dễ bị lệch contract: OpenAPI spec, request trong Bruno và mock response nằm ở nhiều nơi khác nhau.
• Tốn onboarding: Thành viên mới phải cài thêm mock tool, import config và cấu hình local.
• Phải viết payload thủ công: Mỗi status code, mỗi field và mỗi edge case đều cần định nghĩa riêng.
• Dữ liệu quá tĩnh: Stub kiểu "name": "string" không giúp phát hiện lỗi với dữ liệu đa dạng.

Nếu API nhỏ, đây có thể không phải vấn đề lớn. Nhưng khi API phát triển, sự lệch giữa spec, request và mock sẽ làm chậm team.

Để xem thêm các khoảng trống thường gặp trong workflow kiểu Bruno, bạn có thể đọc phân tích về nền tảng API tất cả trong một thay thế Bruno.

Cách tốt hơn: tạo mock server từ OpenAPI spec

Thay vì định nghĩa mock riêng, cách thực tế hơn là tạo mock từ API contract mà team đã duy trì.

Apidog cho phép nhập hoặc viết OpenAPI spec, sau đó tạo mock server từ chính các schema đó. Nghĩa là bạn dùng một nguồn sự thật duy nhất cho thiết kế API, mock, test và tài liệu.

Cách tiếp cận này hữu ích vì:

• Mock từ schema: Field name và data type trong OpenAPI được dùng để tạo response hợp lý.
• Response động: Dữ liệu có thể đa dạng hơn so với một JSON mẫu cố định.
• Không cần tự host server: Endpoint mock được tạo sẵn từ định nghĩa API.
• Ít lệch contract: Khi spec đổi, mock cũng đi theo cùng định nghĩa.

Ví dụ một OpenAPI schema đơn giản:

openapi: 3.0.3
info:
  title: User API
  version: 1.0.0

paths:
  /users:
    get:
      summary: List users
      responses:
        "200":
          description: Danh sách user
          content:
            application/json:
              schema:
                type: array
                items:
                  $ref: "#/components/schemas/User"

components:
  schemas:
    User:
      type: object
      required:
        - id
        - name
        - email
      properties:
        id:
          type: integer
          example: 1
        name:
          type: string
          example: Nguyen Van A
        email:
          type: string
          format: email
          example: [e-mail]

Từ schema này, mock server có thể trả về response đúng cấu trúc:

[
  {
    "id": 1,
    "name": "Nguyen Van A",
    "email": "[e-mail]"
  }
]

Vì mock, request và tài liệu đều dựa trên cùng project, bạn không cần duy trì một nơi thứ ba chỉ để giữ response giả đồng bộ. Nếu team của bạn ưu tiên Git workflow, spec vẫn có thể được review và so sánh như code, phù hợp với quy trình làm việc API Git-native.

Bạn cũng có thể xem thêm các trường hợp sử dụng mock API để xác định phần nào trong quy trình hiện tại nên được mock.

Hướng dẫn nhanh: từ OpenAPI spec đến mock URL

Dưới đây là workflow ngắn gọn để tạo mock từ spec hiện có.

Bước 1: Chuẩn bị OpenAPI hoặc Swagger spec

Bạn có thể dùng file local:

openapi.yaml
openapi.json
swagger.json

Hoặc một URL public/internal trỏ đến spec.

Bước 2: Import spec vào Apidog

Trong Apidog, import OpenAPI/Swagger spec. Các path, method, schema và response definition sẽ được đưa vào project.

Ví dụ các endpoint sau sẽ được nhập theo spec:

GET /users
GET /users/{id}
POST /users
PUT /users/{id}
DELETE /users/{id}

Bước 3: Mở endpoint cần mock

Chọn endpoint, ví dụ:

GET /users

Kiểm tra lại:

• Path
• Method
• Response status code
• JSON schema
• Example nếu có

Mock server sẽ dựa trên các thông tin này để tạo response.

Bước 4: Lấy mock URL

Apidog cung cấp URL mock cho endpoint. Bạn dùng URL này thay cho backend thật trong giai đoạn phát triển.

Ví dụ:

https://mock.example.com/users

Sau đó cấu hình frontend hoặc test suite:

const API_BASE_URL = "https://mock.example.com";

const response = await fetch(`${API_BASE_URL}/users`);
const users = await response.json();

console.log(users);

Bước 5: Test bằng Bruno hoặc curl

Bạn vẫn có thể dùng Bruno để gửi request đến mock URL.

Hoặc test nhanh bằng curl:

curl https://mock.example.com/users

Kết quả trả về là JSON theo schema đã định nghĩa.

Bước 6: Thêm response cho edge case

Khi cần kiểm thử lỗi cụ thể, hãy định nghĩa thêm response trong spec hoặc trong rule mock.

Ví dụ 429 Too Many Requests:

responses:
  "429":
    description: Rate limit exceeded
    headers:
      Retry-After:
        schema:
          type: integer
        example: 60
    content:
      application/json:
        schema:
          type: object
          properties:
            message:
              type: string
              example: Too many requests

Response mong muốn:

{
  "message": "Too many requests"
}

Header:

Retry-After: 60

Case này giúp frontend kiểm thử logic retry, disable button hoặc hiển thị thông báo lỗi mà không cần backend thật phải rate limit.

Khi nào workaround là đủ?

Bạn không nhất thiết phải dùng mock dựa trên OpenAPI trong mọi trường hợp. Bruno cộng với mock tool bên ngoài vẫn đủ nếu:

• Bạn chỉ cần stub một hoặc hai endpoint.
• API nhỏ và ít thay đổi.
• Team đã quen với Mockoon, WireMock hoặc Prism.
• Static response là đủ cho test hiện tại.
• Bạn không cần đồng bộ mock với tài liệu hoặc contract.

Ví dụ nếu bạn chỉ cần mock một endpoint /health:

app.get("/health", (req, res) => {
  res.json({ status: "ok" });
});

Tự viết một server nhỏ như vậy có thể là lựa chọn nhanh nhất.

Nhưng nếu API có nhiều endpoint, nhiều version, nhiều schema và nhiều team cùng làm việc, mock từ OpenAPI spec sẽ giảm rủi ro lệch contract.

Checklist chọn cách mock phù hợp

Dùng checklist này để quyết định:

API chỉ có vài endpoint?
→ Dùng mock server nhỏ hoặc tool bên ngoài là đủ.

API có OpenAPI spec đã duy trì?
→ Tạo mock từ spec để tránh định nghĩa trùng lặp.

Frontend cần phát triển trước backend?
→ Dùng mock URL dựa trên contract.

CI cần test ổn định?
→ Dùng mock server thay vì staging phụ thuộc dữ liệu thật.

Team thường xuyên gặp lệch giữa docs, request và response?
→ Hợp nhất workflow quanh một nguồn spec.

FAQ

Bruno có mock server tích hợp sẵn không?

Không. Bruno là API client để gửi request và chạy test. Nó không có mock server gốc, vì vậy bạn cần dùng công cụ bên ngoài hoặc tự viết server stub rồi trỏ Bruno đến URL đó.

Cách dễ nhất để thêm mock vào workflow kiểu Bruno là gì?

Cách ít lệch nhất là tạo mock từ OpenAPI spec. Công cụ như Apidog đọc spec và tạo mock URL sẵn sàng, giúp bạn dùng một nguồn sự thật cho thiết kế, mock, test và tài liệu.

Tôi có thể tiếp tục dùng Bruno và chỉ thêm mock server bên ngoài không?

Có. Bạn có thể chạy Mockoon, WireMock, Prism hoặc một server Express/FastAPI riêng, rồi trỏ Bruno đến URL đó. Cách này hoạt động, nhưng spec, request và mock data sẽ nằm ở nhiều nơi khác nhau và có thể bị lệch.

Nếu việc duy trì một mock layer riêng bắt đầu tốn nhiều công hơn lợi ích nó mang lại, hãy thử mock dựa trên spec. Nhập OpenAPI file vào Apidog, lấy mock URL và dùng nó cho frontend, mobile app hoặc test suite mà không cần tự host thêm server.