Bài này không giải thích lại API là gì về mặt kỹ thuật, phần đó đã có sẵn ở trang khái niệm riêng. Câu hỏi bài này trả lời khác: một người không viết code, nhưng là người ký hợp đồng thuê phần mềm hoặc thuê đội làm hệ thống, cần biết gì về API để không rơi vào tình huống bị động sau khi đã trả tiền.
Vì sao đây là câu hỏi tiền bạc, không chỉ câu hỏi kỹ thuật
Một doanh nghiệp thuê phần mềm bán hàng, sau một năm muốn nối thêm phần mềm kế toán để không phải nhập tay hai lần. Nếu phần mềm bán hàng có API mở và tài liệu rõ ràng, việc nối thêm mất vài tuần. Nếu phần mềm đó không có API, hoặc có nhưng vendor thu phí truy cập API riêng, hoặc tài liệu API không công khai mà phải xin, doanh nghiệp rơi vào thế bị động: muốn mở rộng cũng không mở rộng được, hoặc phải trả thêm một khoản không lường trước lúc ký hợp đồng ban đầu.
Đây gọi là rủi ro khoá chặt vào vendor (vendor lock-in). API chính là cánh cửa thoát khỏi tình huống đó: có API nghĩa là dữ liệu và chức năng của hệ thống có thể lấy ra, nối vào hệ thống khác, hoặc thậm chí chuyển hẳn sang vendor khác mà không mất trắng dữ liệu cũ.
Bốn câu hỏi nên đặt ra trước khi ký hợp đồng phần mềm
1. Phần mềm này có API không, và API đó công khai hay phải xin riêng
Nhiều phần mềm quảng cáo "có API" nhưng thực chất chỉ mở cho một vài đối tác chọn lọc, hoặc API tồn tại nhưng tài liệu (documentation) không công khai, muốn dùng phải liên hệ hỗ trợ và chờ duyệt. Nên hỏi thẳng: tài liệu API có xem được ngay không, có ví dụ cụ thể không, hay chỉ là một câu trả lời chung chung "có, liên hệ sales để biết thêm".
2. Dùng API có tính phí riêng không, tính theo gì
Một số vendor tính phí truy cập API theo số lượng request mỗi tháng, tách biệt hoàn toàn với phí thuê bao phần mềm chính. Nếu không hỏi trước, doanh nghiệp có thể ký hợp đồng với mức phí thuê bao có vẻ hợp lý, rồi phát hiện chi phí API riêng đội lên đáng kể khi hệ thống vận hành ở quy mô lớn hơn dự kiến ban đầu.
3. Dữ liệu của doanh nghiệp có lấy ra được toàn bộ qua API không, hay chỉ lấy được một phần
Đây là câu hỏi sống còn cho kịch bản xấu nhất: nếu một ngày doanh nghiệp muốn đổi sang phần mềm khác, dữ liệu khách hàng, đơn hàng, lịch sử giao dịch tích luỹ nhiều năm có lấy ra đầy đủ qua API không, hay vendor chỉ cho xuất một file Excel rút gọn không đủ dùng. Vendor uy tín thường trả lời rõ ràng câu này ngay từ đầu; vendor né tránh câu hỏi này là một dấu hiệu cảnh báo.
4. Ai là người chịu trách nhiệm khi API thay đổi và làm hỏng tích hợp đang chạy
Vendor có thể nâng cấp hệ thống và thay đổi cấu trúc API (breaking change), khiến tích hợp đang chạy ổn bỗng dưng lỗi. Vendor tốt sẽ thông báo trước một khoảng thời gian hợp lý (ví dụ 3-6 tháng) và giữ song song phiên bản cũ trong lúc doanh nghiệp cập nhật. Nên hỏi rõ chính sách này trước khi ký, thay vì phát hiện khi hệ thống đã lỗi giữa chừng.
Doanh nghiệp có người kỹ thuật muốn chấm chất lượng API của vendor có thể đối chiếu với các nguyên tắc thiết kế REST API mà founder ALODEV viết cho lập trình viên: đặt tên endpoint, trả lỗi, quản lý phiên bản.
Khi nào doanh nghiệp chưa cần quan tâm sâu tới API
Không phải mọi doanh nghiệp cần đào sâu vấn đề này ngay từ ngày đầu. Nếu quy mô còn nhỏ, chỉ dùng một phần mềm duy nhất và chưa có kế hoạch nối thêm hệ thống khác, câu hỏi về API có thể tạm gác lại. Thời điểm nên nghiêm túc xem xét là khi bắt đầu dùng từ hai phần mềm trở lên cho cùng một quy trình (ví dụ bán hàng và kế toán, hoặc CRM và tổng đài), vì đó là lúc nhu cầu để các hệ thống "nói chuyện" với nhau trở thành thực tế chứ không còn là lý thuyết.
