Test REST API trên trình duyệt: cách dùng, giới hạn CORS và cách đọc kết quả
Công cụ gửi HTTP request tới một endpoint REST bằng chính trình duyệt của bạn và hiển thị mã trạng thái, header phản hồi, nội dung trả về cùng thời gian xử lý. Phù hợp cho những lần kiểm tra nhanh sau khi deploy hoặc khi cần xác nhận một endpoint còn sống, không phải thay thế cho bộ công cụ kiểm thử đầy đủ.
Tính năng nổi bật
- Gửi request với năm phương thức GET, POST, PUT, PATCH và DELETE
- Thêm bao nhiêu header tùy ý theo cặp khóa và giá trị, mặc định sẵn Content-Type là application/json
- Ô nhập body dạng văn bản tự hiện ra khi bạn chọn POST, PUT hoặc PATCH
- Hiển thị mã trạng thái kèm dòng mô tả và tô màu theo nhóm 2xx, 3xx, 4xx, 5xx
- Đo thời gian từ lúc bấm gửi tới lúc nhận xong body, tính bằng mili giây
- Tự nhận biết phản hồi JSON và định dạng lại thành nhiều dòng thụt lề cho dễ đọc
- Liệt kê các header phản hồi mà trình duyệt cho phép đọc
- Nút sao chép toàn bộ body phản hồi sang clipboard
Khi nào một trình gửi request trên trình duyệt là đủ dùng
Không phải lúc nào bạn cũng cần mở một ứng dụng nặng chỉ để xem một endpoint trả về gì. Rất nhiều tình huống thực tế chỉ cần một lần bấm: kiểm tra sau khi vừa deploy xem route mới đã lên chưa, xác nhận một webhook có nhận đúng payload không, xem một API công khai trả về cấu trúc dữ liệu như thế nào trước khi viết code parse, hoặc chỉ để trả lời câu hỏi endpoint chết hay client gọi sai. Công cụ chạy trong tab trình duyệt nên không phải cài gì, dùng được cả trên máy của khách hàng hay máy mượn tạm. Đổi lại, nó chịu đúng các luật mà trình duyệt áp lên mọi trang web: chính sách CORS, giới hạn header được phép đọc và không gửi cookie sang tên miền khác. Hiểu rõ ranh giới đó thì công cụ này rất tiện; hiểu sai thì bạn sẽ mất thời gian đi tìm lỗi ở nơi không có lỗi.
Lợi ích khi sử dụng
- Kiểm tra một endpoint trong vài giây mà không phải cài phần mềm hay đăng nhập
- Thấy ngay mã trạng thái và thời gian phản hồi để khoanh vùng lỗi ở client hay server
- Body JSON được định dạng lại nên đọc cấu trúc dữ liệu dễ hơn nhìn một dòng dài
- Dùng được trên máy bất kỳ, tiện khi đang hỗ trợ khách hàng qua màn hình chia sẻ
- Không có tài khoản, không có đồng bộ, nên không có chuyện request cũ vô tình lộ ra chỗ khác
Các bước gửi một request
- 1Chọn phương thức ở ô bên trái rồi dán URL đầy đủ vào ô kế bên, nhớ giữ nguyên phần https và cả chuỗi query nếu có.
- 2Điều chỉnh phần header: giữ hoặc sửa dòng Content-Type có sẵn, bấm Add để thêm dòng mới cho Authorization hay khóa API.
- 3Nếu bạn chọn POST, PUT hoặc PATCH, ô body sẽ hiện ra, dán chuỗi JSON vào đó và kiểm tra kỹ dấu ngoặc trước khi gửi.
- 4Bấm Send Request rồi đọc mã trạng thái ở cột phải, màu sắc cho biết nhanh request rơi vào nhóm thành công hay lỗi.
- 5Đối chiếu body phản hồi với tài liệu API, dùng nút sao chép nếu cần dán kết quả vào ticket hoặc gửi cho đồng nghiệp.
CORS: vì sao request thất bại dù endpoint vẫn chạy tốt
Công cụ này gọi API bằng hàm fetch của trình duyệt, nên nó chịu đúng chính sách CORS như mọi trang web khác. Khi tên miền của trang khác tên miền của API, trình duyệt yêu cầu máy chủ phải trả về header Access-Control-Allow-Origin cho phép nguồn gọi; nếu request có header lạ hoặc dùng phương thức PUT, PATCH, DELETE, trình duyệt còn gửi trước một request OPTIONS gọi là preflight và chờ máy chủ xác nhận qua Access-Control-Allow-Methods và Access-Control-Allow-Headers. Thiếu bất kỳ mảnh nào trong chuỗi đó, trình duyệt chặn phản hồi và công cụ chỉ nhận được một thông báo lỗi chung chung, không kèm mã trạng thái. Điểm quan trọng cần nhớ: request thường vẫn tới máy chủ và vẫn được xử lý, chỉ là trình duyệt không cho trang đọc kết quả. Nghĩa là một lệnh DELETE bị báo lỗi CORS vẫn có thể đã xóa dữ liệu thật. Với những endpoint không mở CORS, hãy dùng curl hoặc một ứng dụng khách chạy ngoài trình duyệt thay vì tìm cách vô hiệu hóa cơ chế bảo vệ này.
Vì sao danh sách header phản hồi trông ngắn hơn thực tế
Nhiều người mở công cụ rồi thắc mắc tại sao không thấy header X-Request-Id hay X-RateLimit-Remaining mà tài liệu API có nhắc tới. Đây không phải lỗi hiển thị. Với request khác tên miền, trình duyệt chỉ cho JavaScript đọc bảy header mặc định gồm Cache-Control, Content-Language, Content-Length, Content-Type, Expires, Last-Modified và Pragma. Mọi header khác đều bị ẩn trừ khi máy chủ liệt kê tên chúng trong header Access-Control-Expose-Headers. Vì vậy khi cần kiểm tra header tùy chỉnh, bạn có hai lựa chọn: đề nghị phía máy chủ bổ sung tên header vào Access-Control-Expose-Headers, hoặc kiểm tra bằng curl với tùy chọn hiển thị header đầy đủ. Cũng lưu ý là header Set-Cookie không bao giờ đọc được từ JavaScript dù máy chủ có khai báo gì đi nữa, đây là ràng buộc cứng của trình duyệt chứ không phải cấu hình thiếu.
Con số mili giây nói lên điều gì và không nói lên điều gì
Thời gian hiển thị được đo từ ngay trước khi gọi fetch tới ngay sau khi đọc xong toàn bộ body. Nó gộp cả tra cứu DNS, bắt tay TCP, bắt tay TLS, thời gian máy chủ xử lý, thời gian truyền dữ liệu về và cả thời gian trình duyệt phân tích JSON. Vì vậy đừng đọc con số này như thời gian xử lý của backend. Lần gọi đầu tiên tới một tên miền mới thường cao hơn hẳn vì phải thiết lập kết nối; những lần sau kết nối được tái sử dụng nên nhanh hơn. Cách dùng đúng là gửi cùng một request bốn hay năm lần rồi lấy giá trị ở giữa thay vì tin vào lần đo đơn lẻ. Nếu muốn tách riêng phần chờ máy chủ, bạn cần đo Time To First Byte bằng công cụ khác, hoặc so sánh giữa một endpoint trả về ít dữ liệu với một endpoint trả về nhiều dữ liệu trên cùng máy chủ để ước lượng phần thời gian truyền.
Các mã trạng thái hay gặp và cách phân biệt những cặp dễ nhầm
Nhóm 2xx là thành công: 200 kèm dữ liệu, 201 khi vừa tạo mới và thường có header Location trỏ tới tài nguyên, 204 khi thành công nhưng không có body nên vùng nội dung trong công cụ sẽ trống. Nhóm 4xx là lỗi phía người gọi và đây là chỗ hay nhầm nhất. Mã 401 nghĩa là máy chủ không biết bạn là ai, thường do thiếu hoặc sai token; mã 403 nghĩa là máy chủ biết bạn là ai nhưng tài khoản đó không có quyền, đổi token khác cũng vô ích nếu quyền chưa được cấp. Mã 404 là đường dẫn không tồn tại, còn 405 là đường dẫn tồn tại nhưng không nhận phương thức bạn chọn, nên gặp 405 thì hãy xem lại dropdown trước khi sửa URL. Mã 415 xuất hiện khi Content-Type không khớp thứ máy chủ chấp nhận, còn 422 là dữ liệu đúng định dạng nhưng sai quy tắc nghiệp vụ. Nhóm 5xx thì lỗi nằm ở phía máy chủ, riêng 502 và 504 thường chỉ ra vấn đề ở tầng proxy hoặc gateway chứ không phải ở ứng dụng.
Những việc công cụ này không làm và lưu ý về thông tin nhạy cảm
Công cụ không lưu request, nên khi bạn tải lại trang thì URL, header và body đều mất; nếu cần dùng lại nhiều lần hãy lưu ra file riêng hoặc dùng ứng dụng có tính năng bộ sưu tập. Body chỉ nhận văn bản thuần nên không tải file lên được, tức là không kiểm tra được endpoint dạng multipart. Không có biến môi trường, không có tự động lấy lại token, không có kiểm thử theo kịch bản nhiều bước. Cookie cũng không được gửi kèm sang tên miền khác vì fetch mặc định chỉ gửi cookie cùng nguồn, nên các API xác thực bằng phiên đăng nhập sẽ luôn trả về 401 ở đây. Về an toàn, hãy cân nhắc kỹ trước khi dán token quản trị hay khóa API của môi trường thật vào bất kỳ trang web nào, kể cả trang này. Thói quen tốt là tạo một token riêng cho việc kiểm tra, giới hạn quyền ở mức đọc, và thu hồi nó sau khi xong việc.
Câu hỏi thường gặp (FAQ)
Vì sao tôi nhận lỗi Failed to fetch mà không thấy mã trạng thái nào?
Đó gần như luôn là CORS. Trình duyệt đã chặn phản hồi trước khi công cụ kịp đọc, nên không có mã trạng thái để hiển thị. Nguyên nhân khác có thể là URL sai, tên miền không phân giải được, hoặc bạn gọi một địa chỉ http từ trang https. Hãy mở tab Console của trình duyệt, thông báo lỗi ở đó nói rõ hơn nhiều.
Request bị chặn CORS thì máy chủ có thực sự nhận được không?
Có, trong phần lớn trường hợp. CORS chặn ở bước trình duyệt đọc phản hồi chứ không chặn ở bước gửi đi. Riêng những request cần preflight, nếu bước OPTIONS thất bại thì request chính không được gửi. Vì vậy hãy rất cẩn thận khi thử DELETE hay POST trên dữ liệu thật: có thể thao tác đã thực hiện xong dù bạn thấy báo lỗi.
Làm sao gửi token xác thực?
Thêm một dòng header mới với khóa là Authorization và giá trị là Bearer kèm dấu cách rồi tới chuỗi token. Nếu API dùng khóa riêng thì thường là X-API-Key. Kiểm tra kỹ chuỗi dán vào không dính dấu cách thừa hay ký tự xuống dòng, đây là nguyên nhân rất phổ biến khiến bạn nhận 401 dù token vẫn còn hạn.
Vì sao chọn GET mà không thấy ô nhập body?
Ô body chỉ hiện với POST, PUT và PATCH vì đó là các phương thức mang dữ liệu theo thân request. Với GET và DELETE, tham số phải nằm trong chuỗi query trên URL, ví dụ dấu chấm hỏi rồi page bằng 2 và ghép thêm bằng dấu và. Một số máy chủ có nhận body trong GET nhưng đây là cách làm không theo chuẩn và không nên dựa vào.
Tôi gửi JSON mà máy chủ trả về 400, kiểm tra ở đâu?
Trước hết soi lại cú pháp JSON: dấu phẩy thừa ở phần tử cuối, dùng nháy đơn thay vì nháy kép, hoặc thiếu ngoặc đóng là ba lỗi hay gặp nhất. Sau đó xem header Content-Type có đúng application/json không. Cuối cùng đọc body phản hồi, đa số API viết rõ trường nào thiếu hoặc sai kiểu trong thông báo lỗi.
Vì sao tôi không thấy header X-RateLimit hay X-Request-Id trong phần phản hồi?
Với request khác tên miền, trình duyệt chỉ cho phép đọc bảy header cơ bản như Content-Type, Content-Length hay Cache-Control. Những header tùy chỉnh chỉ hiện ra nếu máy chủ khai báo tên chúng trong Access-Control-Expose-Headers. Muốn xem đầy đủ, hãy dùng curl chạy ngoài trình duyệt.
Thời gian phản hồi hiển thị có phải thời gian xử lý của server không?
Không. Con số đó bao gồm cả tra cứu DNS, bắt tay kết nối, thời gian máy chủ xử lý, thời gian tải dữ liệu về và thời gian phân tích JSON. Lần gọi đầu tới một tên miền mới luôn cao hơn các lần sau. Muốn có số liệu đáng tin, hãy gửi vài lần rồi lấy giá trị ở giữa thay vì tin lần đo đầu tiên.
Có gửi được file lên endpoint upload không?
Không. Ô body ở đây chỉ nhận văn bản thuần nên không tạo được request dạng multipart kèm tệp nhị phân. Với những endpoint upload, bạn cần dùng curl với tùy chọn form, hoặc một ứng dụng khách có phần chọn tệp. Đây là giới hạn về tính năng chứ không phải lỗi cấu hình.
Công cụ có gửi cookie đăng nhập của tôi kèm request không?
Không, với API khác tên miền. Hàm fetch mặc định chỉ gửi cookie cùng nguồn, nên những API xác thực bằng phiên đăng nhập sẽ trả về 401 ở đây dù bạn đang đăng nhập trong tab khác. Muốn kiểm tra loại API đó, hãy dùng công cụ khác hoặc chuyển sang xác thực bằng token.
Có lưu lại được các request đã gửi để dùng lần sau không?
Không. Toàn bộ nội dung bạn nhập nằm trong bộ nhớ của tab hiện tại và biến mất khi tải lại trang. Đây là công cụ cho những lần kiểm tra rời rạc. Nếu bạn cần bộ sưu tập request dùng đi dùng lại, biến môi trường hay chạy tự động, hãy dùng phần mềm chuyên cho việc đó.
Kiểm tra được GraphQL hoặc WebSocket không?
GraphQL thì được, vì phần lớn máy chủ GraphQL nhận một request POST với body JSON gồm trường query và trường variables. WebSocket thì không, vì đó là giao thức khác hẳn với vòng đời kết nối riêng và cần công cụ chuyên biệt. Tương tự với gRPC.
Dán token của môi trường production vào đây có an toàn không?
Nên tránh. Nội dung bạn gõ không được gửi đi đâu ngoài chính endpoint bạn gọi, nhưng nguyên tắc chung là không đưa thông tin xác thực của hệ thống thật vào một trang web bên thứ ba. Cách an toàn là tạo token riêng cho việc kiểm tra, giới hạn ở quyền đọc, và thu hồi ngay sau khi xong.
Từ khóa liên quan
- api tester online
- test api online
- test rest api miễn phí
- công cụ test api
- gửi http request online
- kiểm tra api endpoint
- http client online
- postman thay thế online
- test api không cần cài đặt
- lỗi cors khi gọi api
- cách sửa lỗi cors
- http status code là gì
- phân biệt 401 và 403
- test api bằng trình duyệt
- kiểm tra api sau khi deploy
- test webhook online
- gửi request post json
- authorization bearer token
- response time api
- công cụ debug api miễn phí
