Test API Request

Client REST chạy trên trình duyệt — GET/POST/PUT/PATCH/DELETE, header tùy chỉnh, body JSON/XML, đo thời gian response. Postman nhẹ để debug API.

Có góp ý? Báo lỗi, đề xuất tính năng, hoặc chia sẻ suy nghĩ — chúng tôi đọc tất cả

Test API Request - Test REST APIs Trực Tuyến

Mọi tích hợp API đều bắt đầu giống nhau: đọc tài liệu, gửi request thử nghiệm thủ công, kiểm tra response, rồi mới viết code production sau khi xác nhận hợp đồng. Trong nhiều thập kỷ, quy trình đó nghĩa là Postman, Insomnia, curl hoặc HTTPie — đều yêu cầu cài đặt phần mềm. Công cụ này đặt cùng quy trình bên trong tab trình duyệt để bạn có thể gọi endpoint nhanh mà không rời ngữ cảnh phát triển hiện tại. Hỗ trợ mọi verb HTTP chuẩn (GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS), chấp nhận header tùy ý ở dạng JSON sạch (Bearer token Authorization, X-API-Key, Content-Type, Accept-Language, header doanh nghiệp tùy chỉnh), gửi body JSON/XML/form-encoded/raw text, và hiển thị tất cả những gì trả về: mã trạng thái số với reason phrase chuẩn, mọi response header được phân tích và gán nhãn, body được pretty-print nếu parse được JSON hoặc giữ raw nếu không, thời gian round-trip tính bằng ms, và độ dài byte của response. Trở ngại phổ biến nhất khi test API trên trình duyệt là CORS — API công khai thiết kế cho dùng trên trình duyệt (Stripe, GitHub, OpenAI, JSONPlaceholder) hoạt động tốt, nhưng API nội bộ chỉ mong đợi traffic server-to-server sẽ chặn request với header Access-Control-Allow-Origin thiếu. Khi điều đó xảy ra, thông báo lỗi cho biết chính xác cần tìm gì trong cấu hình CORS của server API của bạn.

API Request Tester là gì?

API Request Tester là công cụ cho phép bạn gửi HTTP requests đến APIs và xem responses của chúng. Nó rất quan trọng cho:

- Test API endpoints trong quá trình phát triển
- Debug các vấn đề API
- Khám phá third-party APIs
- Xác minh authentication và authorization
- Test các HTTP methods khác nhau
- Kiểm tra định dạng API response

Nó hoạt động như một client có thể giao tiếp với bất kỳ REST API nào, tương tự như các công cụ Postman hoặc Insomnia.

Làm thế nào để test API?

Test API rất đơn giản:

1. Nhập URL endpoint API
2. Chọn HTTP method (GET, POST, PUT, DELETE, PATCH)
3. (Tùy chọn) Thêm custom headers theo định dạng JSON
4. (Tùy chọn) Thêm request body cho POST/PUT/PATCH requests
5. Nhấp 'Gửi Request'
6. Xem response status, headers, body và timing

Ví dụ GET request:
URL: https://jsonplaceholder.typicode.com/users/1
Method: GET

Ví dụ POST request:
URL: https://jsonplaceholder.typicode.com/posts
Method: POST
Body: {"title": "Test", "body": "Content", "userId": 1}

HTTP methods nào được hỗ trợ?

Công cụ này hỗ trợ tất cả các HTTP methods chuẩn:

- GET: Lấy dữ liệu từ server
- POST: Gửi dữ liệu để tạo resources mới
- PUT: Cập nhật hoàn toàn resources hiện có
- PATCH: Cập nhật một phần resources hiện có
- DELETE: Xóa resources
- HEAD: Chỉ lấy headers (không có body)
- OPTIONS: Kiểm tra các methods được hỗ trợ

Hầu hết APIs sử dụng GET (đọc), POST (tạo), PUT/PATCH (cập nhật) và DELETE.

Làm thế nào để thêm custom headers?

Headers phải được thêm theo định dạng JSON hợp lệ:

{
"Content-Type": "application/json",
"Authorization": "Bearer your-token-here",
"X-Custom-Header": "value"
}

Headers phổ biến:
- Content-Type: Xác định định dạng request body (application/json, text/xml)
- Authorization: Authentication tokens (Bearer, Basic, API keys)
- Accept: Định dạng response mong đợi
- User-Agent: Định danh client
- X-API-Key: Xác thực API key

Headers là các cặp key-value cung cấp metadata về request.

Lỗi CORS là gì?

CORS (Cross-Origin Resource Sharing) là tính năng bảo mật của trình duyệt có thể chặn API requests từ công cụ này:

- Nhiều APIs không cho phép requests từ browsers
- Đây là hành vi bảo mật bình thường
- Public APIs thường có CORS enabled
- Private APIs có thể chặn browser requests

Giải pháp:
- Dùng APIs có hỗ trợ CORS
- Test với browser extensions disable CORS (chỉ để test)
- Dùng công cụ backend cho production testing
- Liên hệ nhà cung cấp API để enable CORS

Để test API nghiêm túc, hãy cân nhắc dùng các công cụ chuyên dụng như Postman, Insomnia hoặc backend testing frameworks.

Khi nào dùng PUT vs PATCH vs POST để cập nhật resource?

Ba verb này trông có thể thay thế cho người mới nhưng có ngữ nghĩa riêng quyết định tính đúng đắn API và hành vi cache. POST TẠO MỚI resource trên server (hoặc kích hoạt action có side effect) — server chọn ID resource mới và trả về vị trí. Dùng cho /users khi đăng ký người dùng mới, /orders khi đặt hàng, /search khi chạy tìm kiếm thay đổi state server. PUT THAY THẾ toàn bộ resource hiện có tại URL đã biết — bạn gửi representation mới đầy đủ, mọi field bạn bỏ qua sẽ reset về null/default. Dùng khi cập nhật object profile đầy đủ của người dùng tại /users/123. PATCH thay đổi một phần resource hiện có — chỉ gửi các field thay đổi, để các field khác nguyên vẹn. Dùng khi chỉ đổi field email tại /users/123. Spec HTTP nói PUT và PATCH phải IDEMPOTENT (gọi cùng PUT/PATCH hai lần tạo cùng end state), trong khi POST không cần (hai POST tới /orders tạo hai đơn). Nhầm điều này và client sẽ retry các POST thất bại và vô tình tạo bản ghi trùng lặp.

Test API Request — Client REST chạy trên trình duyệt — GET/POST/PUT/PATCH/DELETE, header tùy chỉnh, body JSON/XML, đo thời gian response. P — **Test API Request**

Làm sao gửi Bearer token Authorization đúng cách?

Xác thực Bearer là pattern auth API chủ đạo năm 2026 — dùng bởi OAuth 2.0, OpenID Connect, các API dựa trên JWT, và hầu hết nền tảng SaaS hiện đại. Định dạng cố định bởi RFC 6750: giá trị header Authorization PHẢI là từ literal 'Bearer' theo sau bởi đúng một dấu cách và chuỗi token. Trong trường Headers của công cụ này, dán:

{
"Authorization": "Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIn0.dozjgNryP4J3jVmNHl0w5N_XgL0n3I9PlFUP0THsR8U"
}

Lỗi phổ biến: (1) Quên dấu cách sau 'Bearer' — API trả về 401. (2) Dùng chữ thường 'bearer' — RFC nói không phân biệt hoa thường nhưng một số server nghiêm ngặt từ chối. (3) Bao gồm dấu ngoặc '<' '>' từ ví dụ tài liệu một cách literal trong token. (4) Gửi token thô không có prefix 'Bearer' — đó là pattern Basic auth cũ hơn. (5) Tái sử dụng JWT đã hết hạn — giải mã tại jwt.io để kiểm tra claim 'exp'. Đừng bao giờ dán token production trực tiếp vào công cụ không tin cậy; trình test này chạy hoàn toàn trên trình duyệt nhưng bạn vẫn nên rotate bất kỳ token nào đã dùng cho debug sau khi hoàn tất.

Các mã trạng thái HTTP phổ biến có nghĩa là gì (200, 201, 204, 301, 400, 401, 403, 404, 422, 429, 500, 503)?

Mã trạng thái là thứ đầu tiên cần đọc trong mọi response — nó cho biết kết quả trước cả khi bạn nhìn vào body.

2xx thành công:
- 200 OK: request thành công, body chứa kết quả.
- 201 Created: một POST đã tạo tài nguyên mới; kiểm tra header Location để biết URL của nó.
- 204 No Content: thành công với body rỗng (thường gặp ở DELETE và một số PUT/PATCH).

3xx chuyển hướng:
- 301 Moved Permanently: tài nguyên có URL mới — hãy cập nhật endpoint.
- 302/307/308: chuyển hướng tạm thời hoặc giữ nguyên method.

4xx lỗi phía client (request của bạn sai):
- 400 Bad Request: cú pháp sai hoặc tham số không hợp lệ.
- 401 Unauthorized: thiếu hoặc sai xác thực — kiểm tra header Authorization / token.
- 403 Forbidden: đã xác thực nhưng không được phép (quyền/scope).
- 404 Not Found: sai URL hoặc tài nguyên không tồn tại.
- 422 Unprocessable Entity: body parse được nhưng không qua quy tắc kiểm tra.
- 429 Too Many Requests: bị giới hạn tần suất — chờ và kiểm tra header Retry-After.

5xx lỗi phía server (server hỏng):
- 500 Internal Server Error: ngoại lệ không được xử lý trên server.
- 503 Service Unavailable: server quá tải hoặc đang bảo trì; thử lại sau.

Quy tắc chung: 4xx nghĩa là sửa request của bạn, 5xx nghĩa là lỗi thuộc về server.

Tôi có cần đặt header Content-Type khi gửi request body không?

Có — khi bạn gửi body, server dùng Content-Type để quyết định cách parse, và đặt sai là một trong những nguyên nhân phổ biến nhất gây response 400 hoặc 415.

- Body JSON: đặt Content-Type là application/json. Hầu hết API JSON sẽ từ chối hoặc âm thầm bỏ qua body gửi mà không có nó. Body phải là JSON hợp lệ, ví dụ {"name":"Ada"}.
- Dữ liệu form: đặt application/x-www-form-urlencoded và gửi key=value&key2=value2 (định dạng form HTML cổ điển).
- Văn bản thuần/XML: dùng text/plain hoặc application/xml/text/xml để server không cố parse thành JSON.
- Upload file: dùng multipart/form-data (lưu ý: ranh giới multipart thực tế dễ làm hơn từ curl/Postman gốc so với một ô văn bản thô).

Với GET, HEAD, OPTIONS và DELETE không có body, bạn hoàn toàn không cần Content-Type. Cũng nhớ header Accept là tấm gương của Content-Type: nó cho server biết bạn muốn nhận lại định dạng nào (ví dụ Accept: application/json).

Tính năng Sao chép dạng cURL hoạt động như thế nào?

Sau khi gửi một request, hãy nhấn 'Sao chép dạng cURL' để sao chép một lệnh curl sẵn sàng chạy tái hiện chính xác những gì công cụ vừa gửi — cùng URL, cùng method -X, một flag -H cho mỗi header, và một flag --data cho body. Dán nó vào bất kỳ terminal, báo cáo bug, runbook hay script CI nào.

Đây là lối thoát hữu ích nhất khỏi trình duyệt. Vì trình duyệt áp dụng CORS, một số API bị chặn trong công cụ test trên trình duyệt này sẽ chạy hoàn hảo từ curl, vốn không có chính sách same-origin. Vậy nên khi gặp tường CORS, hãy chuyển request sang curl và chạy từ terminal hoặc server để xác nhận bản thân API hoạt động.

Lệnh được tạo ra sẽ đặt dấu nháy đơn và escape URL, header và body để các giá trị chứa khoảng trắng hoặc ký tự đặc biệt vẫn nguyên vẹn. Nó đơn giản, không phụ thuộc thư viện và chạy được trên mọi shell, trở thành định dạng trao đổi phổ quát giữa công cụ test này, đồng đội của bạn và hệ thống tự động hóa.

Dữ liệu của tôi có an toàn không?

Các cân nhắc về quyền riêng tư:

- Requests đi trực tiếp từ trình duyệt của bạn đến API
- Không có dữ liệu nào đi qua servers của chúng tôi
- Chúng tôi không log hoặc lưu trữ bất kỳ request/response data nào
- Hãy cẩn thận với dữ liệu nhạy cảm (passwords, tokens)
- Tránh test với production credentials
- Cân nhắc dùng test/sandbox API endpoints

Mẹo bảo mật:
- Đừng chia sẻ API keys công khai
- Dùng credentials riêng cho từng môi trường
- Test với dummy data khi có thể
- Thu hồi test tokens sau khi dùng