Màn hình tìm thấy đúng tên đơn hàng nhưng yêu cầu cập nhật lại trỏ tới một mã khác ở chữ số cuối. Endpoint vẫn trả dữ liệu hợp lệ, JSON vẫn parse được và không có cảnh báo cú pháp. Với ID dài trong JavaScript, mã có thể đã bị chuyển thành Number trước khi đội tích hợp kịp lưu lại chuỗi gốc. Đổi kiểu ở cuối đường đi không nhất thiết lấy lại được mã ban đầu.
Bài viết theo một ví dụ kỹ thuật giả lập để tìm điểm mất tính chính xác, từ phản hồi API đến khóa đối chiếu và request gửi lại. Nó dành cho người phát triển connector và người nghiệm thu dữ liệu, không hướng dẫn thay ID trong cơ sở dữ liệu đang chạy. Những con số bên dưới là dữ liệu thử cục bộ, không phải mã đơn hàng hoặc kết quả của khách hàng Onter.
ID dài trong JavaScript có thể đổi trước bước mapping
Hãy bắt đầu từ hai dạng phản hồi nhìn rất giống nhau: {"id":9007199254740993} và {"id":"9007199254740993"}. Dạng đầu dùng JSON number, dạng sau dùng JSON string. Với bộ dữ liệu giả này, JSON.parse thông thường cho dạng đầu thành giá trị Number có phần hiển thị cuối là 992; dạng chuỗi giữ nguyên phần cuối 993. Việc nội dung JSON hợp lệ không chứng minh kiểu số phía nhận biểu diễn được mọi chữ số.
MDN về Number.MAX_SAFE_INTEGER nêu giới hạn số nguyên an toàn là 9007199254740991. Vấn đề không phải mọi con số vượt ngưỡng đều lập tức sai; vấn đề là không còn bảo đảm biểu diễn và phân biệt chính xác từng số nguyên liên tiếp. Một ID dùng để chọn bản ghi cần tính bảo toàn, không chỉ một giá trị gần đúng hoặc màn hình trông hợp lý.
Đặc biệt, String(value) sau khi parse chỉ chuyển giá trị đang có sang chữ. Nếu chữ số đã mất trong Number, kết quả là chuỗi của số đã bị làm tròn. Tương tự, thêm dấu ngoặc kép lúc tạo request gửi lại có thể sửa được kiểu truyền nhưng vẫn gửi sai danh tính. Vì vậy, khi điều tra, cần tìm điểm đầu tiên ID bị biến đổi chứ không chỉ nơi cuối cùng phát hiện lỗi.
Điều này khác bài toán API thay kiểu giữa hai phiên bản. Trong tình huống đang xét, hợp đồng từ nguồn có thể chưa đổi, nhưng consumer đã chọn một biểu diễn không đủ chính xác. Bảng hợp đồng trường API vẫn hữu ích để ghi ai phát và ai đọc ID; bài này bổ sung cách kiểm tính nguyên vẹn của chính mã ấy qua cả vòng nhận và gửi.
Đi theo một mã từ nguồn đến yêu cầu gửi lại
Trong buổi nghiệm thu, đừng chỉ hỏi connector đã lưu kiểu string chưa. Chọn một bản ghi giả có mã được xác nhận ở nguồn rồi theo nó qua từng ranh giới. Một luồng có thể gồm văn bản phản hồi, đối tượng sau parse, kết quả mapping, bản lưu tạm, khóa dùng để ghép quan hệ và request ra ngoài. Một lớp giữ chuỗi không cứu được lớp trước đã chuyển thành số.
Ở phản hồi đầu vào, cần biết hợp đồng yêu cầu number hay string. Nếu quyền kiểm tra cho phép, dùng fixture đã loại dữ liệu riêng tư để giữ nguyên token ID trong văn bản trước parse. Không xuất toàn bộ phản hồi thật vào log chỉ để tìm một mã. Với endpoint mà đội không kiểm soát, lưu cả phiên bản tài liệu và mẫu thử được phép để trao đổi với bên cung cấp, thay vì tự sửa nguồn production.
Sau parse, ghi kiểu và giá trị của đúng trường ID trong bộ thử. Đối chiếu với mẫu nguồn đã biết, không dùng màn hình đã format làm chuẩn. Một cột bảng có thể rút gọn số hoặc chuyển sang ký hiệu khoa học; đó là vấn đề hiển thị khác với dữ liệu thực trong đối tượng. Cần phân biệt hai lớp trước khi chọn cách sửa để tránh chỉ làm màn hình dễ nhìn hơn trong khi request vẫn sai.
Tới mapping, rà các thao tác tưởng như vô hại: ép số để so sánh, cộng một giá trị mặc định, chuyển qua cấu trúc có schema số hoặc dùng thư viện tự suy luận kiểu. Không phải thao tác nào cũng đang tồn tại trong mọi connector. Đây là danh sách điểm cần kiểm trên đường đi cụ thể. Chỉ kết luận một bước gây lỗi khi có cặp trước và sau chứng minh cùng ID đã đổi.
Ở nơi ghép quan hệ, hậu quả có thể vượt quá một chuỗi sai trên màn hình. Nếu hai ID khác nhau đã thành cùng một giá trị, một bảng đối chiếu có thể gộp bản ghi hoặc request cập nhật có thể chọn sai đích. Khi phát hiện xung đột, giữ bản ghi chờ xác minh thay vì chọn một kết quả bất kỳ. Không suy ngược mã gốc bằng cách đoán chữ số cuối từ tên hoặc thời gian tạo.
Cuối vòng, tạo request trong môi trường thử rồi đối chiếu token ID gửi ra với token nguồn. Kiểm cả đường tạo bản ghi mới và đường cập nhật đã có nếu hai đường dùng mapping khác nhau. Một kết quả đọc lại đúng tên chưa đủ: hai bản ghi có thể trùng tên. Bằng chứng nên gắn với mã ổn định và thuộc tính tối thiểu được phép đọc, không dùng dữ liệu cá nhân để bù cho việc ID đã hỏng.
Chọn đúng dữ liệu làm chuẩn đối chiếu
Mẫu thử cần có nhiều hơn một số lớn ngẫu nhiên. Một cặp số nguyên liền nhau ở vùng không an toàn giúp phát hiện việc gộp danh tính; một ID ngắn kiểm đường thông thường. Mã có số 0 đầu kiểm yêu cầu bảo toàn ký tự nếu miền dữ liệu cho phép. Trường hợp thiếu ID, null và chuỗi rỗng kiểm nhánh từ chối. Không coi chúng đều là cùng một mã mặc định.
Với mã có số 0 đầu, còn phải hỏi số 0 có thuộc danh tính không. Nếu hệ thống nguồn định nghĩa ID là chuỗi, "0017" và "17" không nên bị gom chỉ vì có cùng giá trị số. Nếu hợp đồng đã quy định dạng chuẩn khác, thực hiện đúng quy tắc đó và lưu quyết định. Bài này không tự đặt một phép chuẩn hóa chung cho mọi đối tác hoặc mọi loại chứng từ.
Giữ ID là chuỗi hay dùng BigInt?
Đối với mã chỉ dùng để tra cứu, so khớp và gửi lại, chuỗi thường là lựa chọn dễ giữ đúng ý nghĩa hơn một kiểu dành cho tính toán. Đó là đề xuất thiết kế cần được hai phía thống nhất, không phải quyền tự đổi number thành string trong API công khai. Consumer khác có thể đang kiểm schema hoặc ký request theo một định dạng cụ thể. Thay hợp đồng cần kiểm các bên đang sử dụng nó.
Nếu đội quản lý nguồn, hãy xét chuyển ID sang chuỗi ngay ở chỗ serialize, đồng thời mô tả kiểu và dạng ký tự được phép. Kiểm cả client, kho dữ liệu trung gian và endpoint nhận lại. Đừng chỉ thêm một ví dụ chuỗi trong tài liệu nhưng serializer thực tế vẫn phát number. Trường hợp cần giữ tương thích, có thể phải thiết kế lộ trình phiên bản hoặc trường thay thế rõ ràng; quyết định phụ thuộc hệ thống hiện hữu.
Nếu không quản lý nguồn, trao đổi nhu cầu truyền chính xác với bên phát. MDN về JSON.parse lưu ý reviver thông thường chạy sau khi giá trị số đã được parse. Tài liệu có cơ chế truy cập source text trong môi trường hỗ trợ, nhưng không nên sao chép một ví dụ rồi cho rằng mọi runtime đang dùng đều có cùng khả năng. Khả năng tương thích và xử lý đúng trường vẫn cần được xác minh riêng.
BigInt có thể biểu diễn số nguyên lớn, nhưng không phải nút bật để sửa tất cả JSON. MDN về BigInt mô tả việc JSON.stringify mặc định không serialize trực tiếp giá trị BigInt. Connector dùng kiểu này cần một quy ước serialize được bên nhận hiểu. Chuyển qua BigInt từ một Number đã làm tròn cũng không khôi phục nguồn ban đầu.
Vì vậy, lựa chọn cần theo công việc của trường. Một bộ đếm cần phép toán khác mã đơn hàng chỉ cần giữ nguyên. Không chuyển mọi trường trông giống số thành BigInt và không vá toàn cục prototype chỉ để vượt một thông báo lỗi khi chưa hiểu các consumer khác. Với phạm vi nhỏ, quy ước cho đúng thuộc tính thường dễ review hơn phép chuyển đổi áp dụng cho mọi giá trị.
Không đổi khóa đang dùng mà chưa xét dữ liệu cũ
Sửa connector cho bản ghi mới chưa giải quyết dữ liệu đã nhận sai. Trước khi chạy lại, xác định phạm vi bị ảnh hưởng và nguồn còn có thể dùng để đối chiếu. Một ID lưu sai không phải lúc nào cũng sửa được bằng phép đảo chiều. Nếu không có bằng chứng đủ tin cậy, đưa bản ghi vào tập cần xác minh. Không xóa quan hệ cũ rồi ghép lại theo tên để làm báo cáo hết lỗi.
Cần phân biệt thay kiểu lưu với thay nghĩa khóa. Chuyển một cột số sang văn bản có thể giữ nguyên những chữ số hiện có, nhưng không chứng minh chúng là chữ số nguồn. Các bảng quan hệ, cache và tác vụ đang chờ cũng có thể đang dùng dạng cũ. Phạm vi khắc phục phải chỉ rõ từng lớp; bài thử mới thành công không phải căn cứ cho một đợt ghi đè lịch sử chưa được duyệt.
Nghiệm thu bằng vòng đi về, không bằng một lần parse
Một tiêu chí nghiệm thu hữu ích là cùng mã thử đi qua đường xử lý thực rồi trở về ở dạng đã thỏa thuận, không mất ký tự và không bị gộp với mã khác. Dùng fixture cục bộ để kiểm phép chuyển đổi trước; sau đó mới kiểm kết nối thử được cho phép. Kết quả kiểm thư viện chỉ chứng minh đoạn mã đó, chưa chứng minh cả website, connector hoặc API đối tác đã được sửa.
Trong bảng kết quả, nên tách giá trị nguồn, kiểu sau parse, mã sau mapping và mã ở request cuối. Ghi phiên bản runtime và đường xử lý được kiểm để lần sau không dựa vào một ảnh chụp không rõ bối cảnh. Chỉ thu bằng chứng tối thiểu, tránh đưa token truy cập hoặc nguyên payload khách hàng vào báo cáo. Nếu bản ghi thử không qua được, dừng đúng luồng đó thay vì retry thao tác ghi trên một mã chưa chắc đúng.
Khi bàn giao, mô tả nơi ID được định nghĩa, nơi được chuyển đổi và cách phản ứng khi nằm ngoài hợp đồng. Việc bảo toàn mã cần được giữ trong các lần sửa mapping tiếp theo, không chỉ trong một ca xử lý sự cố. Nếu cần rà một kết nối website với phần mềm khác, hãy chuẩn bị mẫu giả lập và sơ đồ các lớp đang dùng ID. Giá: Liên hệ. Nhận tư vấn & báo giá theo phạm vi kiểm tra và tích hợp đã thống nhất.
