Cắm API vội, hệ thống trả giá lúc không ngờ nhất
Nhiều lập trình viên chỉ đánh giá nhà cung cấp API bên thứ ba bằng một bản demo nhanh, rồi merge thẳng vào production khi deadline dí sát nút. Không ai kịp hỏi xem dịch vụ đó vận hành ổn định tới đâu khi có sự cố thật.
API bên thứ ba, nói dễ hiểu, là một dịch vụ do công ty khác dựng sẵn. Hệ thống của bạn gọi vào đó để lấy dữ liệu, hoặc để thực hiện một chức năng cụ thể. Gọi API thanh toán để xử lý giao dịch. Gọi API bản đồ để hiện vị trí giao hàng. Bên mình từng chứng kiến không ít dự án bỏ qua hẳn bước đánh giá này ngay từ đầu.
Rủi ro lớn nhất không nằm ở lúc code chạy thử trên máy dev. Nó nằm ở lúc hệ thống đã lên production, có hàng nghìn người dùng thật. API lúc đó đột ngột nghẽn, hoặc đổi cấu trúc dữ liệu mà không báo trước.
Tụi mình từng hỗ trợ một khách hàng vận hành sàn thương mại điện tử nhỏ. Họ tích hợp một API vận chuyển của bên thứ ba chỉ sau một buổi demo nhanh. Ba tháng sau, API đó đổi định dạng dữ liệu trả về mà không hề thông báo trước. Đơn hàng bị treo ở trạng thái đang xử lý suốt hai ngày. Đội chăm sóc khách hàng phải trả lời hàng trăm câu hỏi cùng lúc.
Câu chuyện đó không hiếm. Khi nhà cung cấp thiếu quy trình thông báo thay đổi rõ ràng, rủi ro dồn hết về phía đội kỹ thuật. Họ là người trực tiếp vận hành dịch vụ, nên gánh hậu quả đầu tiên. Đặt đúng câu hỏi trước khi tích hợp giúp dev lường trước phần lớn tình huống này. Nhờ vậy, đội tránh được cảnh xử lý khủng hoảng lúc nửa đêm.
Sai lầm phổ biến bên mình hay gặp là chọn API chỉ dựa vào tính năng, bỏ qua hẳn phần vận hành. Một API nhiều tính năng nhưng tài liệu sơ sài vẫn tiềm ẩn rủi ro cao. Rủi ro đó còn cao hơn cả một API ít tính năng hơn nhưng minh bạch về SLA. SLA là thoả thuận mức dịch vụ, tức bản cam kết bằng văn bản về thời gian phản hồi khi có sự cố.
Mẹo nhỏ tụi mình hay áp dụng: trước khi ký hợp đồng, hãy thử liên hệ đội hỗ trợ của nhà cung cấp trước. Gửi họ một câu hỏi kỹ thuật cụ thể, rồi chờ xem họ phản hồi ra sao. Thời gian họ phản hồi, và độ chính xác của câu trả lời, nói lên rất nhiều về chất lượng vận hành sau này.
Nhiều đội kỹ thuật giờ không chỉ tích hợp API thanh toán hay vận chuyển. Họ còn đang thử tích hợp AI agent vào hệ thống nội bộ doanh nghiệp. Nguyên tắc đánh giá nhà cung cấp trước khi cắm vào hệ thống, xét cho cùng, giống nhau ở mọi loại API. Chỉ khác nhau ở độ phức tạp.
Những câu hỏi cần đặt ra khi đánh giá nhà cung cấp API bên thứ ba
Có hàng chục câu có thể hỏi một nhà cung cấp API. Nhưng chỉ vài câu, hỏi đúng lúc, giúp dev nhìn ra vấn đề mà bản demo hào nhoáng không bao giờ cho thấy.
Câu đầu tiên nên hỏi: tài liệu kỹ thuật có đầy đủ và được cập nhật thường xuyên không. Nói dễ hiểu, tài liệu kỹ thuật là bản hướng dẫn mô tả cách gọi API, tham số cần truyền, và mã lỗi trả về. Một nhà cung cấp nghiêm túc luôn giữ tài liệu sát với phiên bản đang chạy thật. Không phải bản viết từ hai năm trước rồi bỏ quên.
- Tài liệu API có ví dụ gọi thực tế kèm mẫu request và response, hay chỉ liệt kê tên hàm suông?
- Khi API gặp downtime — tức thời gian ngừng hoạt động ngoài kế hoạch — nhà cung cấp có kênh thông báo sự cố không? Thông báo đó có cập nhật theo thời gian thực không?
- Gói dịch vụ đang cân nhắc giới hạn bao nhiêu request mỗi phút, và điều gì xảy ra khi hệ thống vượt ngưỡng đó?
Giới hạn request, hay rate limit, là số lần hệ thống được phép gọi API trong một khoảng thời gian nhất định. Vượt ngưỡng này, có nhà cung cấp chặn luôn request tiếp theo. Có nơi âm thầm tính phí phụ trội. Không hỏi trước con số này, dev dễ bị bất ngờ đúng lúc traffic tăng đột biến. Ví dụ đợt sale cuối năm, lượng đơn gọi API vận chuyển có thể tăng gấp năm lần ngày thường.
Tụi mình từng hỗ trợ một khách hàng đang triển khai lại toàn bộ gian hàng online, dự án dạng https://mona.media/thiet-ke-website-ban-hang/. Họ cũng gặp đúng tình huống này với API vận chuyển. Gói dịch vụ rẻ chỉ cho 60 request mỗi phút. Mùa cao điểm của họ lại cần gấp ba con số đó. Hỏi kỹ ngay từ đầu, đội kỹ thuật đã tránh được một đợt nâng cấp gói khẩn cấp giữa lúc đơn hàng đang dồn.
Chính sách xử lý khi có downtime cũng đáng hỏi kỹ không kém. Một nhà cung cấp minh bạch sẽ công bố mức uptime cam kết, ví dụ 99,9%. Con số đó nghĩa là mỗi năm chỉ được phép gián đoạn khoảng 8 giờ 45 phút. Nghe thì nhỏ, nhưng nếu 8 giờ đó rơi đúng lúc cao điểm bán hàng, thiệt hại tính bằng doanh thu thật.
Sai lầm bên mình từng thấy: nhiều dev chỉ đọc phần giá trên trang chủ nhà cung cấp. Họ bỏ qua hẳn trang chính sách SLA nằm khuất trong footer. Mẹo là hỏi thẳng đội kinh doanh một câu cụ thể: nếu API lỗi làm gián đoạn đơn hàng, bên bạn đền bù thế nào. Câu trả lời ấp úng thường là dấu hiệu cần cân nhắc lại nhà cung cấp khác.
Trước khi tích hợp thật, hãy thử API trong một sân chơi riêng
Đọc tài liệu là một chuyện. Tự tay chạy thử là chuyện khác hẳn, và luôn cho ra nhiều bất ngờ hơn dev tưởng.
Sandbox, nói nôm na, là một môi trường thử nghiệm tách biệt hoàn toàn khỏi hệ thống sản phẩm thật. Gọi API sai, gửi dữ liệu lỗi trong sandbox không ảnh hưởng gì tới khách hàng thật đang dùng ứng dụng. Phần lớn nhà cung cấp API bên thứ ba uy tín đều cấp sẵn tài khoản sandbox miễn phí. Kèm theo thường là dữ liệu mẫu để dev vọc thoải mái trước khi đụng vào dữ liệu thật.
Bên mình có một thói quen cố định. Trước khi đưa bất kỳ API mới nào vào hệ thống chính thức, luôn dành ít nhất một tuần chạy thử trong sandbox. Một lần, tụi mình phát hiện API xác thực khách hàng trả về mã lỗi sai lệch so với tài liệu. Lỗi 401, nghĩa là không có quyền truy cập, lại bị gắn nhầm mã 500, vốn dùng cho lỗi hệ thống. Không test kỹ trước, đội vận hành hẳn đã tưởng server của mình có vấn đề. Mất hàng giờ tra sai chỗ.
Ngoài việc tự thử, tham khảo đánh giá từ cộng đồng developer đã dùng qua API đó cũng đáng làm. Những thảo luận trên GitHub Issues, Stack Overflow hay các nhóm dev thường phơi bày rõ một điều. Đó là những vấn đề mà trang giới thiệu sản phẩm không bao giờ nhắc tới. API đổi phiên bản đột ngột. Đội hỗ trợ im lặng cả tuần. Hoặc một lỗi hiếm chỉ xuất hiện khi traffic lớn — những chuyện chỉ người từng dùng thật mới biết.
Nhân tiện, nếu API đó còn xử lý dữ liệu khách hàng nhạy cảm, có một điều bên mình luôn nhắc anh em. Đó là bảo mật dữ liệu luôn là tiêu chí ưu tiên hàng đầu khi chọn nhà cung cấp. Một API xử lý thanh toán hay thông tin cá nhân mà lơ là bảo mật thì rất đáng lo. Lúc đó, mọi tiêu chí khác gần như không còn ý nghĩa.
Một sai lầm hay gặp là chỉ test đúng luồng thành công, tức trường hợp mọi thứ chạy suôn sẻ. Rồi quên hẳn các tình huống lỗi: mất mạng giữa chừng, timeout, dữ liệu trả về rỗng. Mẹo của tụi mình là viết sẵn một danh sách tình huống lỗi cần giả lập, trước khi bắt đầu sandbox. Đừng để kiểu nghĩ tới đâu test tới đó. Cách làm này không khác gì một checklist kỹ thuật rõ ràng khi chọn đối tác công nghệ. Tụi mình vẫn dùng đúng cách đó cho các dự án tích hợp AI. Nguyên tắc chung đều là kiểm tra bằng dữ liệu thật, không tin hoàn toàn vào lời quảng cáo.
Một điểm nữa ít dev để ý: hỏi luôn về chính sách versioning, tức cách nhà cung cấp quản lý các phiên bản API. Một nhà cung cấp tốt sẽ giữ song song phiên bản cũ và mới trong một khoảng thời gian. Kèm theo đó là changelog rõ ràng, để hệ thống của bạn có thời gian nâng cấp. Thay vì bị ép chuyển đổi trong một đêm.
Câu hỏi đúng lúc, hệ thống đỡ vạ lây về sau
Không có nhà cung cấp API nào hoàn hảo tuyệt đối. Ai cũng từng gặp lỗi, từng có lúc downtime. Khác biệt nằm ở chỗ họ minh bạch tới đâu khi sự cố xảy ra. Và ở chỗ dev có hỏi đủ câu cần hỏi trước khi ký hợp đồng hay không.
Lần tới, trước khi gật đầu chọn một API bên thứ ba, bên mình khuyên bạn dành nửa ngày làm đúng ba việc. Đọc kỹ tài liệu kỹ thuật mới nhất. Hỏi thẳng chính sách downtime và giới hạn request. Rồi tự tay chạy thử trong sandbox ít nhất vài ngày, trước khi đụng vào hệ thống thật. Nửa ngày bỏ ra lúc đầu, đổi lại có thể là hàng chục giờ không phải thức đêm vá lỗi về sau.