Bài 36 – API Key là gì và vì sao tuyệt đối không nên để lộ? thuộc series Tin học BĐS. Bài ưu tiên giải thích bằng tiếng Việt và chỉ giữ các tên kỹ thuật cần thiết để người học có thể thao tác đúng trong công cụ.
Biên soạn: ThS. Nguyễn Mạnh Hùng
Đơn vị: GV. Khoa QLĐĐ&BĐS – ĐH Nông Lâm TP.HCM
Email: nguyenmanhhung@hcmuaf.edu.vn
Cập nhật 01/10/2026: Bài thuộc phần API, JSON và tích hợp dữ liệu của series Tin học BĐS. Nội dung ưu tiên tiếng Việt thuần; chỉ giữ nguyên tên giao thức, định dạng và cú pháp kỹ thuật khi cần thao tác thực tế. Các ví dụ và số liệu đều là tình huống giả lập phục vụ giảng dạy.
Ranh giới chuyên đề: Bài thuộc phần API, JSON và tích hợp dữ liệu. API/JSON/REST được giữ nguyên vì là tên kỹ thuật; các khái niệm còn lại được diễn giải bằng tiếng Việt như yêu cầu, phản hồi, phân trang, khóa API và dòng truy vết nguồn dữ liệu.
1. Khóa API là một chuỗi bí mật hoặc thông tin nhận diện được dịch vụ cấp để biết ai đang gọi API và áp dụng quyền hoặc giới hạn tương ứng
Khóa API là một chuỗi bí mật hoặc thông tin nhận diện được dịch vụ cấp để biết ai đang gọi API và áp dụng quyền hoặc giới hạn tương ứng.
Trong thực hành, mỗi nguyên tắc cần được chuyển thành điều kiện có thể kiểm tra. Người học phải biết dữ liệu đến từ đâu, trường nào có thể rỗng, khóa nào dùng để liên kết, khi nào phải dừng và kết quả sau xử lý phải có đặc điểm gì.
2. Khóa API không nên được xem như mật khẩu người dùng, nhưng vẫn là thông tin nhạy cảm vì người khác có thể dùng nó thay chủ sở hữu để gọi dịch vụ
Khóa API không nên được xem như mật khẩu người dùng, nhưng vẫn là thông tin nhạy cảm vì người khác có thể dùng nó thay chủ sở hữu để gọi dịch vụ.
Trong thực hành, mỗi nguyên tắc cần được chuyển thành điều kiện có thể kiểm tra. Người học phải biết dữ liệu đến từ đâu, trường nào có thể rỗng, khóa nào dùng để liên kết, khi nào phải dừng và kết quả sau xử lý phải có đặc điểm gì.
3. Không được để khóa trong tệp Excel gửi rộng, mã nguồn công khai, ảnh chụp màn hình, bài giảng công khai hoặc ghi thẳng vào tài liệu hướng dẫn
Không được để khóa trong tệp Excel gửi rộng, mã nguồn công khai, ảnh chụp màn hình, bài giảng công khai hoặc ghi thẳng vào tài liệu hướng dẫn.
Trong thực hành, mỗi nguyên tắc cần được chuyển thành điều kiện có thể kiểm tra. Người học phải biết dữ liệu đến từ đâu, trường nào có thể rỗng, khóa nào dùng để liên kết, khi nào phải dừng và kết quả sau xử lý phải có đặc điểm gì.
| Câu hỏi kiểm | Mục đích |
|---|---|
| Nguồn nào? | Truy vết |
| Khóa nào? | Không trùng/không nhầm |
| Rỗng có nghĩa gì? | Không gán sai |
| Có giới hạn/phân trang? | Không thiếu dữ liệu |
| Sau xử lý kiểm gì? | Có bằng chứng |
4. Trong môi trường ứng dụng, nên lưu khóa trong biến môi trường, kho bí mật hoặc cơ chế cấu hình phù hợp thay vì viết trực tiếp trong mã
Trong môi trường ứng dụng, nên lưu khóa trong biến môi trường, kho bí mật hoặc cơ chế cấu hình phù hợp thay vì viết trực tiếp trong mã.
Trong thực hành, mỗi nguyên tắc cần được chuyển thành điều kiện có thể kiểm tra. Người học phải biết dữ liệu đến từ đâu, trường nào có thể rỗng, khóa nào dùng để liên kết, khi nào phải dừng và kết quả sau xử lý phải có đặc điểm gì.
5. Nếu dùng Power Query trên máy cá nhân, cần hiểu nơi công cụ lưu thông tin xác thực và ai có quyền mở tệp hoặc truy cập máy
Nếu dùng Power Query trên máy cá nhân, cần hiểu nơi công cụ lưu thông tin xác thực và ai có quyền mở tệp hoặc truy cập máy.
Trong thực hành, mỗi nguyên tắc cần được chuyển thành điều kiện có thể kiểm tra. Người học phải biết dữ liệu đến từ đâu, trường nào có thể rỗng, khóa nào dùng để liên kết, khi nào phải dừng và kết quả sau xử lý phải có đặc điểm gì.
6. Nên cấp khóa theo nguyên tắc ít quyền nhất, tách khóa giữa môi trường thử nghiệm và chính thức, và thay khóa khi nghi ngờ bị lộ
Nên cấp khóa theo nguyên tắc ít quyền nhất, tách khóa giữa môi trường thử nghiệm và chính thức, và thay khóa khi nghi ngờ bị lộ.
Trong thực hành, mỗi nguyên tắc cần được chuyển thành điều kiện có thể kiểm tra. Người học phải biết dữ liệu đến từ đâu, trường nào có thể rỗng, khóa nào dùng để liên kết, khi nào phải dừng và kết quả sau xử lý phải có đặc điểm gì.
| Câu hỏi kiểm | Mục đích |
|---|---|
| Nguồn nào? | Truy vết |
| Khóa nào? | Không trùng/không nhầm |
| Rỗng có nghĩa gì? | Không gán sai |
| Có giới hạn/phân trang? | Không thiếu dữ liệu |
| Sau xử lý kiểm gì? | Có bằng chứng |
7. Khi khóa bị lộ, cần thu hồi hoặc tạo lại ngay, kiểm nhật ký sử dụng và đánh giá dữ liệu/quyền đã bị truy cập
Khi khóa bị lộ, cần thu hồi hoặc tạo lại ngay, kiểm nhật ký sử dụng và đánh giá dữ liệu/quyền đã bị truy cập.
Trong thực hành, mỗi nguyên tắc cần được chuyển thành điều kiện có thể kiểm tra. Người học phải biết dữ liệu đến từ đâu, trường nào có thể rỗng, khóa nào dùng để liên kết, khi nào phải dừng và kết quả sau xử lý phải có đặc điểm gì.
8. Nhật ký, thông báo lỗi hoặc mã nguồn cũng có thể vô tình làm lộ khóa; cần che thông tin nhạy cảm trước khi chia sẻ
Nhật ký, thông báo lỗi hoặc mã nguồn cũng có thể vô tình làm lộ khóa; cần che thông tin nhạy cảm trước khi chia sẻ.
Trong thực hành, mỗi nguyên tắc cần được chuyển thành điều kiện có thể kiểm tra. Người học phải biết dữ liệu đến từ đâu, trường nào có thể rỗng, khóa nào dùng để liên kết, khi nào phải dừng và kết quả sau xử lý phải có đặc điểm gì.
Bảng trọng tâm
| Rủi ro | Sai lầm | Cách phòng |
|---|---|---|
| Lộ khóa | Đăng ảnh | Che thông tin |
| Dùng chung | Một khóa cho tất cả | Tách quyền |
| Nhúng mã | Viết thẳng trong mã | Biến môi trường/kho bí mật |
| Rò nhật ký | Log đầy đủ khóa | Che khóa |
Tích hợp dữ liệu là một chuỗi có kiểm soát
Khi lấy dữ liệu từ hệ thống khác, quy trình không dừng ở việc 'đã lấy được JSON'. Cần kiểm quyền truy cập, cấu trúc phản hồi, phân trang, kiểu dữ liệu, lỗi, thời gian lấy và khả năng truy vết đến nguồn.
| Lớp | Câu hỏi | Bằng chứng |
|---|---|---|
| Nguồn | Có được phép dùng? | Điều khoản/tài liệu |
| Yêu cầu | Gọi gì? | Địa chỉ + tham số |
| Phản hồi | Nhận gì? | Mã trạng thái + JSON |
| Biến đổi | Đã sửa gì? | Các bước Power Query |
| Đầu ra | Dùng ở đâu? | Bảng/báo cáo |
| Truy vết | Số liệu từ đâu? | Nhật ký nguồn |
Không nhầm 'tự động' với 'đúng'
API giúp lấy dữ liệu tự động nhưng dữ liệu vẫn có thể thiếu, trùng, cũ hoặc thay đổi cấu trúc. Mỗi lần làm mới cần kiểm số bản ghi, tỷ lệ trường rỗng, khóa duy nhất, thời gian cập nhật và lỗi phản hồi.
Quyền sử dụng dữ liệu là một phần của kỹ thuật
Việc một hệ thống cho phép gọi API không tự động có nghĩa người dùng được phép lưu, phân phối hoặc khai thác mọi dữ liệu. Sinh viên cần hình thành thói quen kiểm tài liệu, điều khoản sử dụng và phạm vi quyền trước khi tích hợp.
Khóa API phải được quản trị như tài sản truy cập
Nên biết khóa thuộc ai, cấp quyền gì, dùng ở môi trường nào, khi nào hết hạn và cách thu hồi. Một khóa vô chủ hoặc dùng chung cho cả lớp là rủi ro lớn.
Tình huống giả lập phục vụ giảng dạy
Một sinh viên chụp màn hình Power Query và vô tình để lộ khóa API trong địa chỉ truy vấn rồi đăng lên nhóm lớp. Hãy xây quy trình xử lý ngay và quy tắc phòng ngừa.
Sinh viên phải trình bày cả cấu trúc, thao tác, lỗi có thể gặp và cách kiểm tra. Không chỉ nộp một ảnh chụp bảng dữ liệu hoặc đoạn lệnh chạy được mà phải giải thích đường đi của dữ liệu.
Quy trình thực hành gợi ý
- Xác định nguồn dữ liệu và quyền sử dụng.
- Ghi rõ câu hỏi nghiệp vụ hoặc dữ liệu cần lấy.
- Xác định khóa, trường bắt buộc và giá trị rỗng.
- Thử trên tập nhỏ trước khi lấy toàn bộ.
- Ghi số bản ghi, thời gian và lỗi phản hồi.
- Chuẩn hóa kiểu dữ liệu trước khi phân tích.
- Lưu các bước biến đổi hoặc truy vấn.
- Tạo bảng kiểm để người khác có thể chạy lại.
Tiêu chí chấm bài thực hành
| Tiêu chí | Tỷ trọng gợi ý | Đạt khi |
|---|---|---|
| Hiểu cấu trúc | 25% | Phân biệt đúng đối tượng/trường |
| Kỹ thuật | 25% | Truy vấn/kết nối đúng |
| Kiểm soát lỗi | 20% | Xử lý rỗng, phân trang, mã lỗi |
| Truy vết | 20% | Nguồn và biến đổi rõ |
| Bàn giao | 10% | Người khác chạy lại được |
Bài tập mở rộng
- Tạo bộ dữ liệu giả lập ít nhất 500 BĐS.
- Thiết kế trường có NULL hợp lý và trường bắt buộc.
- Tạo một phản hồi JSON giả lập có đối tượng và mảng.
- Thiết kế quy trình lấy dữ liệu nhiều trang.
- Ghi nhật ký thời gian, tham số và số bản ghi.
- Biến dữ liệu thành bảng và kiểm khóa duy nhất.
- Vẽ dòng truy vết từ nguồn đến một chỉ tiêu báo cáo.
- So sánh phương án API, CSV và sao chép/dán cho cùng bài toán.
Những lỗi thường gặp
- Dùng 0 để thay cho dữ liệu chưa có.
- Dùng địa chỉ làm khóa chính.
- Lặp danh mục ở mọi bảng.
- Không đọc tài liệu API.
- Để lộ khóa API.
- Chỉ lấy trang đầu rồi tưởng đã đủ dữ liệu.
- Mở rộng mảng JSON làm nhân bản dòng mà không biết.
- Làm mới nhưng không kiểm số dòng.
- Không ghi nguồn và thời gian lấy dữ liệu.
- Dùng API dù quy trình đơn giản hơn đã đủ.
Liên hệ công việc BĐS
Trong hệ thống BĐS hiện đại, dữ liệu hiếm khi nằm ở một nơi. Excel, cơ sở dữ liệu, bản đồ, website và phần mềm nội bộ thường phải trao đổi với nhau. Người làm BĐS không nhất thiết trở thành lập trình viên, nhưng cần hiểu dữ liệu được lấy thế nào, vì sao có thể thiếu, cách kiểm nguồn và cách phát hiện khi một chỉ tiêu bị thay đổi do lỗi tích hợp.
Tiêu chí tự đánh giá
| Tiêu chí | Đạt khi |
|---|---|
| Hiểu nghĩa dữ liệu | Không nhầm NULL/0/rỗng |
| Hiểu cấu trúc | Đọc được JSON/API cơ bản |
| An toàn | Không lộ khóa truy cập |
| Đủ dữ liệu | Xử lý phân trang |
| Truy vết | Biết số liệu đến từ đâu |
Câu hỏi tự kiểm tra
- NULL này có nghĩa nghiệp vụ gì?
- API có được phép sử dụng theo mục đích này không?
- Tôi đã lấy đủ mọi trang chưa?
- Khóa API có xuất hiện trong tệp chia sẻ không?
- Sau khi mở rộng JSON, số dòng có tăng ngoài dự kiến không?
- Tôi có thể giải thích con số trên báo cáo đến từ đâu không?
Ghi nhớ trong 30 giây
- Khóa API là một chuỗi bí mật hoặc thông tin nhận diện được dịch vụ cấp để biết ai đang gọi API và áp dụng quyền hoặc giới hạn tương ứng.
- Không được để khóa trong tệp Excel gửi rộng, mã nguồn công khai, ảnh chụp màn hình, bài giảng công khai hoặc ghi thẳng vào tài liệu hướng dẫn.
- Nếu dùng Power Query trên máy cá nhân, cần hiểu nơi công cụ lưu thông tin xác thực và ai có quyền mở tệp hoặc truy cập máy.
- Khi khóa bị lộ, cần thu hồi hoặc tạo lại ngay, kiểm nhật ký sử dụng và đánh giá dữ liệu/quyền đã bị truy cập.
- Nhật ký, thông báo lỗi hoặc mã nguồn cũng có thể vô tình làm lộ khóa; cần che thông tin nhạy cảm trước khi chia sẻ.
Nguồn tham khảo
- Đề cương học phần 612421 – Tin học ứng dụng trong bất động sản, Trường Đại học Nông Lâm TP.HCM.
- Kế hoạch 96 chủ đề website – series Tin học BĐS trong hệ thống BDSNL.
- PostgreSQL Documentation – tài liệu chính thức về NULL, mô hình quan hệ và truy vấn SQL.
- Microsoft Support – tài liệu chính thức về Power Query và kết nối dữ liệu web.
- MDN Web Docs và tài liệu kỹ thuật JSON/HTTP – tham khảo về yêu cầu, phản hồi, mã trạng thái và dữ liệu JSON.
- Nguyên tắc quản trị dữ liệu: nguồn gốc, tính mới, khóa truy cập, nhật ký biến đổi và khả năng truy vết.
Bài tiếp theo: “Pagination là gì? Vì sao API chỉ trả 100 bản ghi mỗi lần?”.
Gợi ý kiểm tra chéo trong lớp
Một nhóm chuẩn bị dữ liệu nguồn hoặc phản hồi JSON, nhóm khác chỉ được nhận tài liệu kết nối và phải tái lập bảng kết quả. Nếu không xác định được trang tiếp theo, trường rỗng hay nguồn chỉ tiêu, nhóm thiết kế phải bổ sung tài liệu.
Sau khi kiểm chéo, sinh viên ghi lại ít nhất ba lỗi hoặc điểm chưa rõ và đề xuất cách sửa. Mục tiêu là hình thành thói quen coi tích hợp dữ liệu là quy trình cần kiểm soát, không phải thao tác kỹ thuật một lần.
Gợi ý kiểm tra chéo trong lớp
Một nhóm chuẩn bị dữ liệu nguồn hoặc phản hồi JSON, nhóm khác chỉ được nhận tài liệu kết nối và phải tái lập bảng kết quả. Nếu không xác định được trang tiếp theo, trường rỗng hay nguồn chỉ tiêu, nhóm thiết kế phải bổ sung tài liệu.
Sau khi kiểm chéo, sinh viên ghi lại ít nhất ba lỗi hoặc điểm chưa rõ và đề xuất cách sửa. Mục tiêu là hình thành thói quen coi tích hợp dữ liệu là quy trình cần kiểm soát, không phải thao tác kỹ thuật một lần.
Gợi ý kiểm tra chéo trong lớp
Một nhóm chuẩn bị dữ liệu nguồn hoặc phản hồi JSON, nhóm khác chỉ được nhận tài liệu kết nối và phải tái lập bảng kết quả. Nếu không xác định được trang tiếp theo, trường rỗng hay nguồn chỉ tiêu, nhóm thiết kế phải bổ sung tài liệu.
Sau khi kiểm chéo, sinh viên ghi lại ít nhất ba lỗi hoặc điểm chưa rõ và đề xuất cách sửa. Mục tiêu là hình thành thói quen coi tích hợp dữ liệu là quy trình cần kiểm soát, không phải thao tác kỹ thuật một lần.
Gợi ý kiểm tra chéo trong lớp
Một nhóm chuẩn bị dữ liệu nguồn hoặc phản hồi JSON, nhóm khác chỉ được nhận tài liệu kết nối và phải tái lập bảng kết quả. Nếu không xác định được trang tiếp theo, trường rỗng hay nguồn chỉ tiêu, nhóm thiết kế phải bổ sung tài liệu.
Sau khi kiểm chéo, sinh viên ghi lại ít nhất ba lỗi hoặc điểm chưa rõ và đề xuất cách sửa. Mục tiêu là hình thành thói quen coi tích hợp dữ liệu là quy trình cần kiểm soát, không phải thao tác kỹ thuật một lần.
Gợi ý kiểm tra chéo trong lớp
Một nhóm chuẩn bị dữ liệu nguồn hoặc phản hồi JSON, nhóm khác chỉ được nhận tài liệu kết nối và phải tái lập bảng kết quả. Nếu không xác định được trang tiếp theo, trường rỗng hay nguồn chỉ tiêu, nhóm thiết kế phải bổ sung tài liệu.
Sau khi kiểm chéo, sinh viên ghi lại ít nhất ba lỗi hoặc điểm chưa rõ và đề xuất cách sửa. Mục tiêu là hình thành thói quen coi tích hợp dữ liệu là quy trình cần kiểm soát, không phải thao tác kỹ thuật một lần.