Tìm hiểu request của REST API

Trước khi mở Postman, hãy xác định API yêu cầu những gì và sẽ trả về kết quả như thế nào. Một request thường chứa phương thức HTTP, URL, header, tham số truy vấn và đôi khi có cả phần thân request. Ví dụ, một API sản phẩm có thể sử dụng GET https://api.example.com/products/42 để truy xuất sản phẩm 42, trong khi POST https://api.example.com/products dùng để tạo sản phẩm mới.

Hãy bắt đầu với tài liệu API và ghi lại phương thức, endpoint, phương thức xác thực và định dạng dữ liệu bắt buộc. Kiểm tra xem dịch vụ yêu cầu JSON, form data hay các tham số truy vấn như category=books. Sự chuẩn bị này giúp tránh một lỗi phổ biến ở người mới: thay đổi nhiều cài đặt cùng lúc mà không biết phần nào đã gây ra lỗi.

Tạo workspace và environment trong Postman

Tạo một workspace Postman cho dự án và nhóm các request vào những thư mục như Users, Products và Orders. Việc sắp xếp các request liên quan cùng nhau giúp bạn dễ dàng lặp lại một quy trình và so sánh kết quả. Một dự án nhỏ có thể chỉ cần mười request, nhưng cách tổ chức rõ ràng sẽ trở nên rất hữu ích khi collection phát triển lên hàng chục endpoint.

Sử dụng biến môi trường cho những giá trị thay đổi giữa môi trường development, staging và production. Thay vì nhập địa chỉ máy chủ đầy đủ vào từng request, hãy lưu địa chỉ đó dưới dạng biến base URL và tham chiếu đến biến một cách nhất quán. Cách làm tương tự cũng áp dụng cho access token, user ID hoặc phiên bản API, đồng thời giúp giảm nguy cơ vô tình gửi request đến nhầm máy chủ và tránh phải chỉnh sửa lặp đi lặp lại.

Gửi request GET trước

Một yêu cầu GET là bước kiểm tra ban đầu hữu ích vì thông thường nó chỉ đọc dữ liệu mà không thay đổi máy chủ. Nhập endpoint, chọn GET, thêm thông tin xác thực nếu cần, rồi gửi yêu cầu. Nếu endpoint là https://api.example.com/users/15, hãy xác minh rằng phản hồi thể hiện người dùng 15, thay vì chỉ xác nhận rằng máy chủ đã trả về dữ liệu nào đó.

Sau khi gửi yêu cầu, hãy kiểm tra mã trạng thái, thời gian phản hồi, các header và phần body. Trạng thái 200 thường cho biết yêu cầu thành công, nhưng bạn cũng nên xác nhận rằng các trường như id, email hoặc createdAt có kiểu dữ liệu và giá trị đúng như mong đợi. Nếu phản hồi là một mảng rỗng, hãy đối chiếu các tham số truy vấn và dữ liệu kiểm thử trước khi kết luận rằng API bị lỗi.

Kiểm thử POST, PUT và DELETE một cách an toàn

Chỉ viết các yêu cầu làm thay đổi dữ liệu sau khi thao tác đọc đã hoạt động chính xác. Với yêu cầu POST, hãy chọn đúng định dạng body, thường là JSON thô, và gửi một payload hợp lệ, nhỏ gọn, chẳng hạn gồm tên sản phẩm, giá và số lượng tồn kho. Xác nhận rằng máy chủ trả về phản hồi tạo mới phù hợp, chẳng hạn trạng thái 201, đồng thời kiểm tra bản ghi được trả về có mã định danh do hệ thống sinh ra.

Hãy kiểm thử dữ liệu không hợp lệ và dữ liệu biên một cách có chủ đích, cũng như dữ liệu hợp lệ. Thử bỏ thiếu trường name bắt buộc, nhập giá âm, mô tả dài bất thường hoặc ngày không hợp lệ, sau đó kiểm tra xem API có trả về phản hồi 4xx rõ ràng thay vì tạo dữ liệu bị lỗi hay không. Với các yêu cầu PUT, PATCH và DELETE, whenever possible, hãy sử dụng một bản ghi kiểm thử riêng để các thử nghiệm không chỉnh sửa hoặc xóa thông tin khách hàng thực.

Kiểm tra mã trạng thái, header và JSON

Đừng đánh giá một yêu cầu chỉ dựa trên mã trạng thái. Hãy kiểm tra các header phản hồi để xem kiểu nội dung, cơ chế bộ nhớ đệm, mã định danh yêu cầu và thông tin giới hạn tốc độ; sau đó xác nhận rằng body là JSON hợp lệ khi hệ thống mong đợi JSON. Phản hồi có trạng thái 200 nhưng lại chứa trang lỗi HTML, thiếu trường hoặc có kiểu nội dung không chính xác vẫn được xem là một lần kiểm thử thất bại đối với client sử dụng API.

Hãy sử dụng các kiểm tra thực tế cho những kết quả HTTP phổ biến. Một lần đăng nhập hợp lệ có thể trả về 200, tài nguyên mới được tạo có thể trả về 201, yêu cầu không hợp lệ có thể trả về 400, thông tin xác thực bị thiếu có thể trả về 401, còn người dùng đã xác thực nhưng không có quyền có thể nhận trạng thái 403. Việc phân biệt các trường hợp này giúp lập trình viên khắc phục đúng nguyên nhân thay vì liên tục thay đổi body của yêu cầu.

Thêm các bài kiểm thử Postman để thực hiện các bước kiểm tra lặp lại

Kiểm tra thủ công hữu ích trong quá trình khám phá, nhưng kiểm thử tự động giúp việc xác minh lặp lại trở nên nhanh hơn. Trong Postman, hãy thêm các bài kiểm thử để xác nhận mã trạng thái, ngưỡng thời gian phản hồi, loại nội dung và sự hiện diện của các trường quan trọng. Ví dụ, một endpoint người dùng có thể xác minh rằng phản hồi có mã 200 và đối tượng được trả về chứa giá trị id và email.

Hãy thiết lập các assertion đủ cụ thể để phát hiện lỗi hồi quy nhưng không quá cứng nhắc khiến chúng dễ bị phá vỡ. Kiểm tra sự tồn tại của id thường bền vững hơn so với việc kỳ vọng một giá trị số cố định, trong khi kiểm tra email có khớp với định dạng hợp lệ hay không có thể phát hiện các phản hồi sai định dạng. Hãy chạy lại cùng một collection sau khi thay đổi mã và điều tra lỗi đầu tiên trước khi cho rằng mỗi lỗi tiếp theo đều có nguyên nhân riêng.

Hoàn tất với Danh sách kiểm tra gỡ lỗi thực tế

Khi một request thất bại, hãy đối chiếu lần lượt từng mục gồm phương thức, URL, tham số truy vấn, header, thông tin xác thực và body với tài liệu. Hãy tìm những khác biệt nhỏ như thiếu dấu gạch chéo, token hết hạn, header Content-Type có giá trị không chính xác hoặc cú pháp JSON có dấu phẩy ở cuối. Hãy tái tạo request với payload nhỏ nhất có thể để dễ cô lập nguồn gây lỗi hơn.

Trước khi chia sẻ một collection, hãy xóa mật khẩu thật, dữ liệu cá nhân và token production khỏi các ví dụ cũng như biến đã lưu. Ghi lại mã trạng thái dự kiến và một phản hồi đại diện cho mỗi request quan trọng, sau đó chạy collection trên một môi trường kiểm thử an toàn. Bước rà soát cuối cùng này biến Postman từ một công cụ dùng để nhấp Send thủ công thành một danh sách kiểm tra có thể lặp lại nhằm xác thực toàn bộ quy trình làm việc của REST API.

Bài viết liên quan

Đọc thêm

Postman

REST API

Mã trạng thái HTTP