Bước gọi HTTP là ô dự phòng của mọi công cụ kết nối kéo thả: khi ứng dụng bạn cần chưa có trong danh sách kết nối sẵn, nhưng có API, bước này cho bạn tự gửi yêu cầu tới nó. Tên gọi khác nhau tuỳ công cụ, có nơi gọi là HTTP request, có nơi gọi là gọi API hay webhook gửi đi, nhưng các ô cần điền gần như giống hệt.
Bài này đi qua từng ô theo thứ tự thường gặp, giải thích nên điền gì, chỉ ra những lỗi người mới hay mắc, và cách đọc kết quả trả về để nối sang các bước sau. Không có dòng mã nào; mọi thứ là điền ô và chọn từ danh sách.
Khi nào cần đến bước gọi HTTP
Công cụ kết nối thường có thư viện hàng trăm ứng dụng đã gói sẵn. Bạn chọn ứng dụng, chọn hành động như tạo dòng, gửi email, và công cụ tự lo phần gọi API bên dưới. Bước gọi HTTP chỉ cần khi gặp một trong ba tình huống.
Tình huống thứ nhất: ứng dụng không có trong thư viện. Phần mềm quản lý bán hàng trong nước, phần mềm chấm công, hệ thống nội bộ do công ty khác viết thường rơi vào trường hợp này. Thứ hai: ứng dụng có trong thư viện nhưng thiếu đúng hành động bạn cần, ví dụ gói sẵn có tạo đơn nhưng không có cập nhật ghi chú đơn. Thứ ba: bạn muốn gọi một dịch vụ mô hình AI với tuỳ chọn mà bước AI có sẵn không cho chỉnh.
Trước khi dùng bước gọi HTTP, kiểm lại kỹ thư viện một lần nữa, kể cả các bản kết nối do cộng đồng làm và phần tìm kiếm theo tên hành động. Kết nối gói sẵn tự lo xác thực, tự xử lý phân trang, tự làm mới mã truy cập; tự làm bằng bước HTTP thì những việc đó thành việc của bạn. Gói sẵn có thì dùng gói sẵn, đây là nguyên tắc tiết kiệm công sửa chữa về sau.
Các ô cần điền và cách điền
Thứ tự các ô có thể khác nhau giữa các công cụ, nhưng nội dung cần điền bám sát tài liệu API của ứng dụng đích.
| Ô trong công cụ | Điền gì | Lỗi hay gặp |
|---|---|---|
| Phương thức | GET để lấy dữ liệu, POST để tạo mới, PUT hoặc PATCH để sửa, DELETE để xoá, đúng như tài liệu ghi cho điểm cuối đó | Dùng GET cho điểm cuối yêu cầu POST, nhận lỗi không cho phép phương thức |
| Địa chỉ | Địa chỉ gốc của API ghép với đường dẫn điểm cuối | Thiếu phần phiên bản trong đường dẫn, thừa hoặc thiếu dấu gạch chéo, dùng địa chỉ môi trường thử khi muốn chạy thật |
| Tham số truy vấn | Các cặp tên và giá trị dùng để lọc, sắp xếp, chọn trang | Gõ sai hoa thường của tên tham số, ngày tháng sai định dạng tài liệu yêu cầu |
| Tiêu đề | Khoá xác thực theo đúng tên tài liệu quy định, và kiểu nội dung là JSON khi gửi dữ liệu | Quên tiền tố bắt buộc trước khoá, đặt khoá vào tham số trong khi tài liệu bảo đặt ở tiêu đề |
| Nội dung | Khối JSON theo mẫu của tài liệu, các ô giá trị lấy từ bước trước | Thiếu dấu ngoặc hoặc dấu phẩy, chuỗi chứa dấu nháy kép làm vỡ cấu trúc |
| Xác thực | Nhiều công cụ có ô riêng chọn kiểu xác thực và lưu khoá an toàn | Bỏ trống ô này rồi dán khoá vào tiêu đề, khiến khoá hiện trần cho ai xem luồng |
Mẹo nhỏ: nếu công cụ có ô lưu thông tin xác thực dùng lại, hãy dùng nó thay vì gõ khoá thẳng vào tiêu đề. Khoá sẽ không hiện trên màn hình luồng, và đổi khoá chỉ phải sửa một chỗ.
Nối dữ liệu từ bước trước vào yêu cầu
Chèn biến thay vì gõ cố định. Phần lớn công cụ cho bạn bấm vào ô rồi chọn một trường của bước trước, như mã đơn từ webhook hay email khách từ biểu mẫu. Ô đó sẽ hiện một khối màu thay cho chữ thường. Khi luồng chạy, khối màu được thay bằng giá trị thật.
Chú ý định dạng giá trị. Tài liệu API có thể yêu cầu số chứ không phải chữ, ngày theo dạng năm trước tháng sau, số điện thoại có mã quốc gia. Dữ liệu từ biểu mẫu thường là chữ thô. Thêm một bước định dạng ở giữa thay vì hy vọng API tự hiểu.
Dấu nháy kép trong dữ liệu người dùng. Khi bạn tự viết khối JSON rồi chèn biến vào giữa, một lời nhắn của khách có dấu nháy kép sẽ làm vỡ cấu trúc và luồng báo lỗi cú pháp. Nhiều công cụ có chế độ nhập nội dung theo từng cặp tên và giá trị, tự lo phần này; dùng chế độ đó khi có.
Ô rỗng. Trường tuỳ chọn mà khách bỏ trống sẽ gửi đi giá trị rỗng. Có API chấp nhận, có API báo lỗi. Đặt giá trị mặc định hoặc thêm điều kiện bỏ qua trường khi rỗng.
Chỉ gửi trường cần thiết. Đừng chuyển cả khối dữ liệu của bước trước sang API đích chỉ vì tiện. Ứng dụng đích không cần biết lịch sử mua hàng của khách để tạo một lịch hẹn; mỗi trường thừa là một lần dữ liệu cá nhân đi thêm một chặng.
Thử bước gọi HTTP an toàn
Bước gọi HTTP có thể ghi dữ liệu thật ngay lần chạy đầu. Thử theo thứ tự này để không phải dọn dẹp hậu quả.
- Dùng môi trường thử hoặc tài khoản thử của ứng dụng đích nếu có. Nếu không có, tạo một khách hàng hay sản phẩm giả để làm đối tượng thử, đặt tên dễ nhận ra như Khách Thử Nghiệm.
- Bắt đầu bằng một yêu cầu GET đọc đúng đối tượng giả đó, xác nhận khoá và địa chỉ đều ổn.
- Chuyển sang yêu cầu ghi, dùng dữ liệu mẫu của chính công cụ hoặc bản ghi giả, chạy riêng bước này một lần.
- Mở ứng dụng đích kiểm bằng mắt xem dữ liệu ghi vào đúng chỗ, đúng định dạng, tiếng Việt có dấu hiển thị đúng.
- Chạy cả luồng từ đầu với một lần kích hoạt giả, chẳng hạn gửi biểu mẫu bằng thông tin giả định.
- Xoá các bản ghi thử khỏi ứng dụng đích, rồi mới bật luồng cho dữ liệu thật.
Đừng bật chế độ chạy theo lịch dày hay nhận webhook thật khi chưa qua đủ các bước trên. Một luồng ghi sai chạy mỗi phút có thể tạo hàng trăm bản ghi rác trong một buổi sáng.
Đọc kết quả trả về và nối sang bước sau
Sau khi chạy, bước gọi HTTP trả về ba thứ: mã trạng thái, phần tiêu đề phản hồi và phần nội dung. Mã trạng thái cho biết thành hay bại; nhóm hai trăm là thành công, nhóm bốn trăm thường là lỗi phía yêu cầu của bạn, nhóm năm trăm là lỗi phía máy chủ bên kia. Phần nội dung là dữ liệu hoặc lời giải thích lỗi, thường ở dạng JSON.
Nhiều công cụ tự tách nội dung JSON thành các trường để bạn chọn ở bước sau. Nếu công cụ chỉ hiện một khối chữ dài, tìm tuỳ chọn phân tích phản hồi dạng JSON và bật lên. Khi dữ liệu là một danh sách, ví dụ mười đơn hàng, bạn cần một bước lặp để xử lý từng đơn; không có bước lặp thì các bước sau chỉ thấy cả khối và ghi một dòng duy nhất chứa mọi thứ.
Một chi tiết quan trọng: theo mặc định, có công cụ coi mọi phản hồi là thành công miễn nhận được trả lời, kể cả khi mã là bốn trăm linh một. Luồng sẽ chạy tiếp với dữ liệu lỗi và ghi những dòng vô nghĩa. Bật tuỳ chọn dừng khi mã không thành công, hoặc thêm một bước điều kiện kiểm mã trạng thái ngay sau bước gọi.
Ví dụ giả định: ghi chú giao hàng từ biểu mẫu sang phần mềm bán hàng
Ví dụ giả định: một nhà phân phối gạo nhỏ ở Đồng Tháp nhận yêu cầu đổi giờ giao qua biểu mẫu, rồi nhân viên phải mở phần mềm bán hàng, tìm đơn, gõ lại ghi chú. Phần mềm có trong thư viện của công cụ kéo thả, nhưng gói sẵn chỉ có tạo đơn và đọc đơn, không có sửa ghi chú. Tài liệu API của phần mềm thì có điểm cuối sửa đơn, phương thức PATCH, nhận một trường ghi chú.
Luồng được dựng như sau. Biểu mẫu gửi về mã đơn và giờ giao mong muốn. Bước gọi HTTP thứ nhất dùng GET đọc đơn theo mã, để chắc đơn tồn tại và chưa giao; bước điều kiện dừng luồng nếu đơn đã ở trạng thái hoàn tất. Bước gọi HTTP thứ hai dùng PATCH, nội dung chỉ gồm trường ghi chú, giá trị ghép từ chữ cố định Khách xin đổi giờ giao sang với giờ lấy từ biểu mẫu. Cuối cùng, luồng gửi tin vào nhóm chat của tổ giao hàng.
Điểm đáng học ở ví dụ này là bước đọc trước khi ghi. Nó tốn thêm một lượt gọi, nhưng chặn được trường hợp khách gõ sai mã đơn khiến luồng sửa nhầm đơn của người khác. Luồng cũng không gửi tên hay số điện thoại khách sang nhóm chat, chỉ mã đơn và giờ mới, đủ để tổ giao hàng tra cứu.
Giới hạn lượt gọi và chi phí khi tự gọi API
Khi dùng kết nối gói sẵn, công cụ thường tự giãn nhịp để không vượt giới hạn của ứng dụng đích. Với bước gọi HTTP tự làm, việc đó là của bạn. Một luồng lặp qua năm trăm khách để cập nhật từng người sẽ bắn năm trăm yêu cầu liên tiếp và nhiều khả năng bị chặn với mã bốn trăm hai mươi chín giữa chừng, để lại nửa danh sách đã cập nhật, nửa chưa.
Cách xử lý: thêm bước chờ ngắn trong vòng lặp, chia danh sách thành nhiều lần chạy, hoặc tìm trong tài liệu điểm cuối cho phép cập nhật hàng loạt một lần nhiều bản ghi. Nhớ rằng công cụ kéo thả nhiều loại tính phí theo số bước hay số lần chạy; vòng lặp năm trăm lần có thể tốn bằng cả tháng dùng bình thường. Ví dụ giả định: một luồng chạy mỗi giờ, mỗi lần lặp qua năm mươi bản ghi, mỗi bản ghi ba bước, sẽ tiêu hơn trăm nghìn bước mỗi tháng, đủ vượt mức miễn phí của nhiều công cụ.
Trước khi bật một luồng có vòng lặp, ước lượng số lượt gọi mỗi ngày bằng phép nhân đơn giản, rồi so với giới hạn của ứng dụng đích và hạn mức gói công cụ của bạn. Kiểm bảng giới hạn hiện hành của từng bên vì chúng thay đổi theo thời gian.
Câu hỏi thường gặp
Bước gọi HTTP có phải là viết mã không?
Không. Bạn điền ô và chọn từ danh sách, giống điền một biểu mẫu chi tiết. Phần khó nhất là đọc đúng tài liệu API để biết điền gì, chứ không phải cú pháp lập trình.
Gọi được rồi nhưng tiếng Việt bị lỗi phông khi ghi sang ứng dụng đích thì sao?
Kiểm tiêu đề kiểu nội dung có khai báo bảng mã UTF-8 không, và kiểm dữ liệu gốc từ bước trước đã đúng dấu chưa. Phần lớn API hiện đại dùng UTF-8 mặc định, lỗi thường nằm ở bước chuyển đổi trung gian.
Nên dùng bước gọi HTTP hay nhờ lập trình viên?
Bước gọi HTTP đủ cho các việc đọc, tạo, sửa từng bản ghi với xác thực bằng khoá. Khi API đòi ký từng yêu cầu bằng thuật toán riêng, cần xử lý khối lượng lớn, hay luồng đụng tới tiền thật, nên nhờ lập trình viên.
Có thể dùng bước gọi HTTP để lấy dữ liệu từ trang web bất kỳ không?
Về kỹ thuật có thể gọi tới nhiều địa chỉ, nhưng lấy dữ liệu từ trang web không cung cấp API, nhất là khi điều khoản cấm, là cào dữ liệu và có thể vi phạm quy định. Chỉ dùng API chính thức và trong phạm vi điều khoản cho phép.
Làm sao biết bước gọi HTTP đã chạy thật hay chỉ chạy thử?
Xem lịch sử chạy của luồng: nhiều công cụ đánh dấu lần chạy thử riêng. Cách chắc nhất là mở ứng dụng đích xem bản ghi có xuất hiện không, và kiểm địa chỉ đang trỏ tới môi trường thử hay môi trường thật.
Bước gọi HTTP báo hết thời gian chờ thì làm gì?
Có thể máy chủ bên kia chậm hoặc yêu cầu quá nặng. Thử lại với ít dữ liệu hơn, tăng thời gian chờ nếu công cụ cho chỉnh, và kiểm xem bản ghi có thực sự được tạo chưa trước khi chạy lại để tránh tạo trùng.