Trong quá trình phát triển, việc chuẩn hóa dữ liệu phản hồi của các giao diện là rất quan trọng. Với các thông số kỹ thuật giao diện liên quan, ngay cả khi gặp sự cố trong các vòng lặp sau, các nhà phát triển và kiểm tra có thể nhanh chóng xác định nguyên nhân của vấn đề.
Để kiểm tra xem cấu trúc dữ liệu được trả về bởi một giao diện có được chuẩn hóa hay không, bạn có thể sử dụng mô-đun tài liệu API của Apidog. Đầu tiên, các cấu trúc dữ liệu chung sẽ được giới thiệu, tiếp theo là một ví dụ để trải nghiệm thiết kế của các cấu trúc dữ liệu.
Ví dụ
1. Vấn đề
Giả sử có một kịch bản mà một đối tượng có hai thuộc tính:
type: enum
values: array
Khi giá trị type được cố định, chiều dài của values nên là 1; khi giá trị type là range, chiều dài của values nên là 2; khi giá trị type là khác, không có giới hạn về chiều dài của values.
Trong kịch bản này, làm thế nào chúng ta có thể giới hạn chiều dài của values dựa trên giá trị type trong Apidog? Để có thể trả về phản hồi lỗi nếu mối quan hệ giữa type và values không thể khớp?
Trước tiên, liệt kê tất cả các thông số kỹ thuật cấu trúc dữ liệu có thể dựa trên yêu cầu:
// Type A
{
"type": "fixed",
"values": ["1"]
}
// Type B
{
"type": "range",
"values": ["1","2"]
}
// Type C
{
"type": "other",
"values": ["1","2","89","67"]
}
2. Định nghĩa Mock Dữ liệu
Để giải quyết vấn đề trong ví dụ một cách thuận tiện hơn, chúng tôi sử dụng chức năng advanced Mock của Apidog để cung cấp dữ liệu giao diện. Theo mô tả của vấn đề, chúng tôi cần định nghĩa 5 loại dữ liệu Mock khác nhau, chia thành 3 xác minh thành công và 2 xác minh thất bại, như sau:
Khi giá trị type là fixed, chiều dài của values nên là 1:
Khi giá trị type là range, chiều dài của values nên là 2:
Khi giá trị type là khác, không có giới hạn về chiều dài của values:
Khi giá trị type là fixed, chiều dài của values không phải là 1:
Khi giá trị type là range, chiều dài của values không phải là 2:
Sau khi định nghĩa dữ liệu Mock, bạn có thể gọi giao diện và xác minh xem cấu trúc dữ liệu trong phản hồi trả về có được chuẩn hóa hay không.
3. Định nghĩa một Phản hồi Thành công
Theo các yêu cầu đã đề cập ở trên, có ba tình huống tương ứng cho dữ liệu phản hồi dự kiến và dữ liệu phản hồi trả về, nếu không sẽ trả về một phản hồi lỗi.
3.1 Thông số 1: Phản hồi thành công của tham số cố định
Đặt type thành kiểu chuỗi, thêm giá trị liệt kê của cố định; đặt values thành kiểu mảng, và giới hạn số lượng phần tử đầu ra chỉ là 1, với các phần tử kiểu chuỗi bên trong. Các chi tiết như sau:
3.2 Thông số 2: Phản hồi thành công của tham số range
Đặt type thành kiểu chuỗi, thêm giá trị liệt kê của range; đặt values thành kiểu mảng, và giới hạn số lượng phần tử tối đa và tối thiểu là 2, với các phần tử kiểu chuỗi bên trong. Các chi tiết như sau:
3.3 Thông số 3: Phản hồi thành công của tham số khác
Đặt type thành kiểu chuỗi, thêm giá trị liệt kê của khác; đặt values thành kiểu mảng, không giới hạn về số lượng phần tử tối đa và tối thiểu, với các phần tử kiểu chuỗi bên trong. Các chi tiết như sau:
Sau khi định nghĩa ví dụ phản hồi thành công, người dùng có thể xác định xem dữ liệu giao diện trả về có tuân thủ thông số kỹ thuật thông qua trạng thái phản hồi khi thực hiện yêu cầu qua giao diện hay không.
4. Xác minh Dữ liệu Phản hồi
Dữ liệu phản hồi và thông số kỹ thuật phản hồi trả về phải tương ứng, nếu không xác minh sẽ thất bại. Trong quá trình gọi giao diện, cần xác minh và kiểm tra kịp thời các kết quả trả về để đảm bảo tính chính xác và đầy đủ của các kết quả trả về. Điều này có thể giảm thiểu hiệu quả xác suất thất bại hoặc lỗi gọi giao diện, đảm bảo tính nhất quán và độ tin cậy của giao diện, và giảm chi phí bảo trì trong giai đoạn sau.
4.1 Xác minh Thông số 1
Chuyển đổi "Xác minh Phản hồi" sang "Thành công Cố định (200)" nghĩa là chỉ một giá trị trong mảng "values" được xuất ra để xác nhận thành công khi type được đặt thành "fixed".
Nhập giá trị 1 vào trường tham số và nhấp vào nút "Gửi". Khi dữ liệu phản hồi được định nghĩa trước tương ứng với các thông số kỹ thuật mong đợi, nó sẽ thông báo một xác nhận thành công ✅.
Nếu giá trị của type không phải là fixed, cấu trúc dữ liệu trả về đã thất bại trong xác minh ❌:
Nếu giá trị của values là null hoặc nhiều hơn 1, cấu trúc dữ liệu trả về đã thất bại trong xác minh ❌:
4.2 Thành công Range(200)
Chuyển "Xác minh Phản hồi" sang "Thành công Range(200)". Điều này chỉ ra rằng chỉ có hai giá trị được coi là một xác nhận thành công trong mảng values khi giá trị type là range.
Nếu giá trị của type không phải là range, cấu trúc dữ liệu trả về đã thất bại trong xác minh ❌:
Nếu giá trị của values là null hoặc không phải 2 giá trị, xác minh cấu trúc dữ liệu cũng sẽ thất bại ❌:
4.3 Thành công Khác(200)
Chuyển "Xác minh Phản hồi" sang "Thành công Khác (200)" có nghĩa là với giá trị type là other, bất kỳ số lượng giá trị nào trong mảng "values" sẽ dẫn đến một xác nhận thành công. ✅
Nếu giá trị của type không phải là other, cấu trúc dữ liệu trả về sẽ thất bại trong xác minh ❌:
Tóm tắt
Ngoài trường hợp trên, bạn cũng có thể chuẩn hóa các cấu trúc dữ liệu khác trong Apidog để kiểm tra xem dữ liệu giao diện có được chuẩn hóa hay không. Apidog cũng hỗ trợ nhiều tính năng khác, như nhập giao diện, dữ liệu giả, và kiểm thử tự động. Nhấn vào liên kết để đọc bài viết gốc và trải nghiệm nó cho riêng bạn!