API là cái quầy gọi món giữa hai phần mềm: một bên đưa yêu cầu theo mẫu đã quy định, bên kia làm việc trong bếp của mình rồi trả kết quả ra quầy, và không bên nào cần biết bếp của bên kia trông ra sao. Chữ API viết tắt từ tiếng Anh, tạm dịch là giao diện lập trình ứng dụng, nhưng cái tên đó làm nhiều người tưởng chỉ dân lập trình mới phải biết.
Thực tế, ngày nay chủ cửa hàng, nhân viên văn phòng hay người bán hàng online đều đụng tới API mỗi khi nối ứng dụng này với ứng dụng kia bằng công cụ kéo thả. Bài này giải thích API bằng ví dụ đời thường, chỉ ra những chữ bạn sẽ gặp trên màn hình cài đặt, và vạch ranh giới giữa việc bạn tự làm được với việc nên nhờ người viết mã.
Ví dụ quầy gọi món: ba vai trong một lần gọi API
Hình dung một quán phở đông khách. Người phục vụ không chạy vào bếp tự nấu; họ ghi phiếu theo mẫu của quán: số bàn, món, cỡ tô, ghi chú không hành. Phiếu đưa qua ô cửa, bếp đọc phiếu, nấu, rồi đặt tô ra kèm số bàn. Nếu phiếu ghi món quán không có, bếp trả phiếu lại kèm một câu ngắn: không có món này.
Một lần gọi API diễn ra y như vậy. Ứng dụng muốn hỏi đóng vai người phục vụ, thường gọi là bên gọi hay máy khách. Ứng dụng có dữ liệu đóng vai cái bếp, gọi là bên cung cấp hay máy chủ. Ô cửa có quy định mẫu phiếu chính là API: nó nói rõ được hỏi những gì, phải ghi những ô nào, và câu trả lời sẽ có dạng ra sao.
Điểm đáng nhớ là bếp không cho người phục vụ vào kho. Bên cung cấp chỉ mở ra những việc họ muốn mở: xem đơn hàng, tạo khách mới, lấy danh sách sản phẩm. Những thứ khác vẫn đóng. Vì vậy hai phần mềm cùng hỗ trợ API chưa chắc đã nối được với nhau theo ý bạn, vì ô cửa của bên kia có thể không có đúng món bạn cần. Trước khi lên kế hoạch một luồng tự động, câu đầu tiên luôn là: ứng dụng đó có mở việc này qua API không.
Những chữ bạn sẽ gặp khi nối ứng dụng
Điểm cuối (endpoint). Là địa chỉ cụ thể của một việc trong API, giống từng ô trên phiếu gọi món ứng với từng loại món. Một API có thể có hàng chục điểm cuối: một chỗ để lấy đơn hàng, một chỗ để tạo khách hàng, một chỗ để cập nhật tồn kho.
Phương thức. Cho biết bạn muốn làm gì với điểm cuối đó. Hay gặp nhất là GET để lấy dữ liệu về xem, POST để tạo mới, PUT hoặc PATCH để sửa, DELETE để xoá. Với người mới, nhớ được GET là đọc và POST là gửi lên đã đủ đi được khá xa.
Tham số và nội dung gửi kèm. Là những ô bạn điền trên phiếu: mã đơn hàng cần tra, ngày bắt đầu, số dòng muốn lấy. Nội dung gửi kèm thường viết theo dạng JSON, một kiểu ghi dữ liệu thành từng cặp tên và giá trị, người thường đọc vẫn hiểu.
Xác thực. Là cách bếp biết phiếu này do người của quán gửi chứ không phải người lạ. Có thể là một khoá API dài, có thể là màn hình đăng nhập rồi bấm cho phép. Phần này có bài riêng vì nó quyết định an toàn của cả luồng.
Phản hồi và mã trạng thái. Mỗi lần gọi đều nhận về một con số cho biết kết quả, ví dụ 200 là ổn, 404 là không tìm thấy, 429 là gọi dồn dập quá. Kèm theo con số là dữ liệu hoặc lời giải thích lỗi.
Vì sao người không lập trình vẫn nên hiểu API
Các nền tảng kết nối kéo thả đã gói sẵn API của nhiều ứng dụng phổ biến thành những ô chọn: chọn ứng dụng, chọn sự kiện, chọn hành động. Bạn đang dùng API mà không thấy chữ API nào. Cách gói này tiện, nhưng nó che mất ba điều mà sớm muộn bạn sẽ phải đối mặt.
Thứ nhất, gói sẵn chỉ bao gồm những việc nền tảng thấy phổ biến. Việc bạn cần, chẳng hạn lấy thêm trường ghi chú nội bộ của đơn hàng, có thể nằm trong API của ứng dụng gốc nhưng không có trong ô chọn. Hiểu API giúp bạn biết việc đó làm được, chỉ là phải dùng bước gọi trực tiếp. Thứ hai, khi luồng hỏng, thông báo lỗi thường là mã trạng thái và một dòng tiếng Anh từ API gốc; đọc được nó giúp bạn tự sửa trong mười phút thay vì chờ người hỗ trợ cả ngày.
Thứ ba, hiểu API giúp bạn hỏi đúng câu khi mua phần mềm. Một phần mềm quản lý bán hàng không có API, hoặc có nhưng chỉ cho đọc mà không cho ghi, sẽ trói dữ liệu của bạn trong đó. Câu hỏi có API không, mở những việc gì, giới hạn bao nhiêu lượt, nên được hỏi trước khi ký, không phải sau khi đã nhập ba năm dữ liệu.
API khác xuất tệp, khác đăng nhập tay ở chỗ nào
Có ba cách đưa dữ liệu từ ứng dụng này sang ứng dụng khác. Bảng dưới đặt cạnh nhau để bạn thấy API đứng ở đâu.
| Cách làm | Ví dụ | Ưu điểm | Hạn chế |
|---|---|---|---|
| Làm tay | Nhân viên mở phần mềm bán hàng, chép đơn mới sang bảng tính giao hàng | Không cần cài gì, ai cũng làm được | Tốn công mỗi ngày, dễ chép sai, chậm khi đơn nhiều |
| Xuất tệp rồi nhập | Cuối ngày xuất danh sách đơn ra tệp, mở bảng tính và dán vào | Nhanh hơn làm tay, không cần quyền đặc biệt | Vẫn cần người bấm, dữ liệu chỉ mới theo từng đợt, dễ dán trùng |
| Qua API | Luồng tự động hỏi phần mềm bán hàng định kỳ hoặc nhận báo ngay khi có đơn, ghi thẳng vào bảng | Chạy không cần người, dữ liệu gần như tức thời, ít sai chép | Phải cài đặt ban đầu, phải giữ khoá cẩn thận, có giới hạn lượt gọi |
Không phải việc gì cũng đáng chuyển sang API. Một báo cáo mỗi tháng xem một lần thì xuất tệp là đủ. API đáng công khi việc lặp hằng ngày, khối lượng tăng dần, hoặc chậm vài giờ là mất khách, ví dụ đơn hàng cần đóng gói trong ngày.
Một ví dụ giả định trọn vẹn: tiệm bánh nhận đơn đặt trước
Ví dụ giả định: một tiệm bánh ở Cần Thơ nhận đặt bánh sinh nhật qua biểu mẫu trên trang web, rồi chủ tiệm chép từng đơn vào bảng tính để thợ làm theo ngày giao. Mùa cao điểm có hôm hơn ba mươi đơn, chép sai ngày giao là chuyện từng xảy ra.
Khi dùng công cụ kết nối, luồng có thể như sau. Biểu mẫu có sẵn chức năng báo đi mỗi khi có người gửi, đây là webhook. Công cụ kết nối nhận báo, rồi gọi API của bảng tính với phương thức gửi lên để thêm một dòng mới gồm tên bánh, cỡ, ngày giao, lời chúc. Nếu chủ tiệm muốn một bước AI tóm gọn phần ghi chú dài của khách thành một dòng cho thợ đọc, công cụ gọi tiếp API của một mô hình ngôn ngữ, gửi phần ghi chú đã bỏ tên và số điện thoại của khách, nhận về câu tóm tắt.
Ở đây có ba lần dùng API mà chủ tiệm không gõ dòng mã nào. Việc của người chủ là hiểu luồng đi qua những chặng nào, dữ liệu gì của khách đi qua chặng nào, và ai giữ khoá của từng chặng. Đó cũng là lý do cần biết API ở mức khái niệm.
Những việc bạn tự làm được và những việc nên nhờ người viết mã
Ranh giới dưới đây không cứng, nhưng giúp bạn khỏi mất cả tuần loay hoay với việc vượt sức, hoặc ngược lại khỏi thuê người cho việc tự làm trong một buổi.
- Tự làm được: nối hai ứng dụng mà công cụ kéo thả đã có sẵn ô chọn, thêm bước lọc, bước định dạng ngày giờ, bước AI tóm tắt hay phân loại.
- Tự làm được với chút kiên nhẫn: dùng bước gọi API trực tiếp theo tài liệu, khi tài liệu có ví dụ rõ và chỉ cần một khoá API.
- Nên nhờ người: khi API yêu cầu ký từng yêu cầu bằng thuật toán riêng, khi cần xử lý hàng chục nghìn bản ghi một lần, khi phải dựng máy chủ riêng để nhận dữ liệu.
- Nên nhờ người: khi luồng đụng tới tiền thật như hoàn tiền, chuyển khoản, xuất hoá đơn điện tử, vì sai một lần là thiệt hại khó gỡ.
- Không làm, dù ai bảo: dùng API để lấy dữ liệu của người khác mà không được phép, hoặc vượt giới hạn lượt gọi bằng cách tạo nhiều tài khoản.
Khi phân vân, hãy mô tả việc cần làm cho một chatbot AI và hỏi nó việc này cần những bước API nào, có chỗ nào phải viết mã không. Câu trả lời giúp bạn ước lượng độ khó, nhưng vẫn phải đối chiếu với tài liệu thật của ứng dụng vì AI có thể đoán sai tên điểm cuối hoặc nhớ phiên bản API đã cũ.
Bắt đầu học API theo cách nào cho đỡ ngợp
Đừng bắt đầu bằng việc đọc định nghĩa trên các trang chuyên cho lập trình viên. Hãy bắt đầu từ một việc lặp mà bạn đang làm tay mỗi tuần, rồi lần ngược lên: dữ liệu nằm ở ứng dụng nào, cần đưa tới ứng dụng nào, hai ứng dụng đó có trong danh sách kết nối sẵn của công cụ bạn đang dùng không. Phần lớn trường hợp, câu trả lời là có, và bạn học API một cách tự nhiên qua những ô chọn.
Khi gặp ca không có sẵn, mở trang tài liệu API của ứng dụng, tìm đúng điểm cuối cho việc bạn cần, xem ví dụ yêu cầu và ví dụ phản hồi. Có thể dán đoạn tài liệu đó vào chatbot AI kèm câu lệnh như: Giải thích đoạn tài liệu API này cho người không biết lập trình, cho biết cần điền những ô nào và ô nào bắt buộc. Nhớ xoá khoá API hay mã bí mật nếu đoạn dán có chứa, vì tài liệu ví dụ đôi khi tự điền khoá thật của tài khoản đang đăng nhập.
Tính năng của các công cụ thay đổi khá nhanh, tên nút và vị trí menu mỗi năm một khác, nên hãy học theo nguyên lý: ai gọi ai, gửi gì, nhận gì, bằng khoá nào. Nắm bốn câu đó, đổi công cụ nào bạn cũng thích nghi được.
Câu hỏi thường gặp
API có phải là một phần mềm cần cài lên máy không?
Không. API là cánh cửa mà một phần mềm mở sẵn để phần mềm khác trao đổi dữ liệu. Bạn không cài API, bạn chỉ dùng nó thông qua công cụ kết nối hoặc nhờ người viết mã gọi tới, cùng với khoá hoặc quyền được cấp.
Ứng dụng nào cũng có API phải không?
Không phải. Nhiều ứng dụng lớn có API công khai, nhưng không ít phần mềm quản lý bán hàng, phần mềm nội bộ hay ứng dụng nhỏ không mở API, hoặc chỉ mở cho gói trả phí cao. Hỏi nhà cung cấp trước khi định xây luồng dựa vào nó.
Gọi API có tốn tiền không?
Tuỳ bên cung cấp. Có API miễn phí trong giới hạn lượt gọi, có API tính theo số lượt hoặc theo khối lượng dữ liệu, như API của các mô hình AI thường tính theo lượng chữ xử lý. Công cụ kết nối kéo thả cũng có thể tính theo số lần luồng chạy. Kiểm bảng phí hiện hành của từng bên.
API và webhook khác nhau thế nào?
Gọi API là bạn chủ động hỏi, giống gọi điện đi hỏi đơn hàng đã có chưa. Webhook là bên kia chủ động báo khi có chuyện xảy ra, giống chuông cửa reo khi có khách. Hai thứ thường đi cùng nhau trong một luồng.
Có nên nhờ AI viết sẵn cấu hình gọi API cho mình không?
Có thể nhờ để hiểu nhanh, nhưng phải đối chiếu với tài liệu chính thức vì AI có thể bịa tên trường hoặc dùng phiên bản API cũ. Không dán khoá API thật vào khung chat, chỉ dùng ký hiệu thay thế khi hỏi.
Học API có cần biết tiếng Anh không?
Tài liệu API đa phần viết bằng tiếng Anh, nhưng từ vựng lặp đi lặp lại khá ít. Biết nghĩa vài chục chữ như request, response, field, required, limit là đọc được phần lớn. Chatbot AI dịch và giải thích đoạn tài liệu khá tốt.