Stack Exchange API bằng Python: lấy câu hỏi theo tag, có lab

Stack Exchange API bằng Python là cách đọc câu hỏi công khai trên Stack Overflow và các site cùng mạng qua endpoint chính thức, thay vì tải trang HTML. Anh em nhận JSON có sẵn question_id, link, tag, điểm số và ngày tạo, chỉ cần lo phân trang, quota và backoff. ProxyVN chạy thật ngày 29/10/2026: ba trang tag python-requests và proxy trả 90 câu hỏi không trùng ID, quota không khóa dừng ở 300 request mỗi ngày, và proxy chỉ đứng ở tầng tải, không đổi được quota.

Stack Exchange API bằng Python: mục tiêu dữ liệu, quyền và phạm vi truy cập

Trước khi viết dòng code nào, anh em nên chốt mình cần dữ liệu gì và được phép lấy tới đâu. Stack Exchange có API công khai, nên phần lớn nhu cầu đọc câu hỏi không cần tới trình duyệt hay đăng nhập.

Dữ liệu nào nên lấy qua API

Bài này nhắm vào metadata câu hỏi: question_id, tiêu đề, link, tag, điểm, số câu trả lời, trạng thái đã có trả lời hay chưa, ngày tạo và ngày hoạt động cuối. Bộ trường này đủ để làm bảng theo dõi chủ đề, đo xu hướng tag hoặc lọc câu hỏi cần trả lời.

Nội dung thân câu hỏi cũng lấy được qua filter withbody. Lab cho thấy cùng hai câu hỏi, bản có thân bài nặng 6.204 byte, trong khi bản mặc định ba mươi câu chỉ khoảng 21 KB. Nếu không cần thân bài thì đừng kéo về, vì vừa tốn băng thông vừa phải xử lý giấy phép nội dung kỹ hơn.

Quyền sử dụng nội dung

Mỗi câu hỏi trả về có trường content_license. Nội dung do người dùng đóng góp trên mạng Stack Exchange được cấp phép theo các phiên bản Creative Commons BY-SA, tùy thời điểm đăng. Khi tái sử dụng tiêu đề hay thân bài ở nơi công khai, anh em cần ghi nguồn và giữ đúng điều kiện chia sẻ.

Metadata dùng nội bộ để thống kê ít rủi ro hơn, nhưng vẫn nên giữ link gốc và question_id cho từng dòng. Khi cần trích dẫn, link đó là bằng chứng xuất xứ. Bài này không tư vấn pháp lý, anh em cần đọc điều khoản hiện hành trước khi đưa dữ liệu vào sản phẩm.

Không thu thông tin cá nhân

Response mặc định có khối owner gồm tên hiển thị, user_id, ảnh đại diện và link hồ sơ. Script trong bài cố ý bỏ khối này khi ghi CSV. Mục tiêu là bảng câu hỏi, không phải danh bạ người dùng.

API công khai không trả email người dùng, và anh em cũng không nên tìm cách lấy email qua đường khác. Nếu dự án cần thông tin tài khoản, đó là việc của OAuth với sự đồng ý của chính người dùng, nằm ngoài phạm vi bài này.

Phạm vi của bài và ranh giới với scrape giao diện

Bài này chỉ dùng phiên bản API 2.3 với endpoint /questions. Không đăng nhập, không dùng access_token, không đăng ký app key. Mọi số liệu trong bài đến từ request ẩn danh, nên quota là quota chung theo IP.

Scrape trang HTML của Stack Overflow là bài toán khác. Trang HTML có giao diện thay đổi, có chống bot và không trả quota rõ ràng như API. Bài Web Scraping proxy là gì giải thích khi nào cần scrape. Với Stack Exchange, API đã trả đủ trường nên không có lý do tải HTML.

Ai dùng bảng câu hỏi này

Nhóm hỗ trợ kỹ thuật dùng bảng câu hỏi để biết người dùng hay gặp lỗi gì với thư viện của mình. Nhóm nội dung dùng nó để chọn chủ đề hướng dẫn. Nhóm sản phẩm dùng nó để đo một tag tăng hay giảm theo thời gian.

Cả ba nhu cầu đều không cần dữ liệu thời gian thực từng giây. Chạy một lần mỗi ngày, lưu lại, so sánh với hôm trước là đủ. Nhịp chạy chậm như vậy cũng giúp quota 300 request không bao giờ là vấn đề.

Những gì bài không làm

Bài không hướng dẫn đăng câu hỏi, sửa câu trả lời hay vote qua API. Các thao tác ghi cần access_token và quyền của người dùng thật. Bài cũng không hướng dẫn vượt quota bằng cách đổi IP, vì điều khoản throttle của API coi việc lạm dụng là lý do để cắt request.

Stack Exchange API bằng Python: đọc câu hỏi theo tag, xử lý paging, backoff và filter

Phần này đi vào cơ chế của endpoint /questions: tham số nào điều khiển kết quả, trường nào trong wrapper cho biết khi nào dừng, và filter làm gì với kích thước response.

Endpoint và tham số cơ bản

Endpoint là https://api.stackexchange.com/2.3/questions. Tham số bắt buộc duy nhất là site, ví dụ stackoverflow. Tham số tagged nhận nhiều tag ngăn bằng dấu chấm phẩy, và câu hỏi phải mang đủ các tag đó mới được trả về.

Tham số sort nhận activity, votes, creation, hot, week hoặc month. Tham số order nhận asc hoặc desc. Lab dùng sort=creation và order=desc để lấy câu mới nhất trước, vì thứ tự theo ngày tạo ít thay đổi giữa hai lần gọi hơn thứ tự theo hoạt động.

Wrapper chung của mọi response

Wrapper của response

Mọi response của API 2.3 nằm trong một wrapper chung. Trường items chứa dữ liệu. Trường has_more cho biết còn trang sau hay không. Trường quota_max và quota_remaining cho biết quota trong ngày. Trường backoff, nếu có, yêu cầu chờ một số giây.

Lab đọc cả bốn trường này sau mỗi trang. Trang 1 báo quota_remaining 294 trên quota_max 300, trang 3 còn 292. Con số đầu không phải 300 vì cùng IP đã gọi vài request trước đó trong ngày. Đây là dấu hiệu quota tính theo IP, không theo script.

page, pagesize và has_more

Theo tài liệu phân trang, page bắt đầu từ 1, pagesize nhận giá trị từ 0 tới 100 và mặc định là 30. Khi has_more là false thì dừng. Không cần tự tính tổng số trang.

Lab thử pagesize=101 để xem API báo lỗi thế nào. Kết quả là mã 400 với error_id 400, error_name bad_parameter và error_message pagesize. Lỗi trả về dạng JSON có cấu trúc, nên script có thể đọc error_name để quyết định sửa tham số hay thử lại.

Đặt pagesize=100 khi cần lấy nhiều, vì mỗi trang tốn một request quota dù nhỏ hay lớn.

Backoff là lệnh, không phải gợi ý

Tài liệu throttle ghi rõ: khi response có trường backoff, ứng dụng phải chờ đủ số giây đó trước khi gọi lại cùng method. Backoff được đặt theo nhiều yếu tố, nên có lúc xuất hiện, có lúc không với cùng tham số.

Trong lab, cả ba trang đều không có backoff. Script vẫn có nhánh đọc backoff và ngủ đúng số giây. Nhánh này không chạy trong lab không có nghĩa là thừa. Khi chạy hàng ngày trên nhiều tag, sớm muộn anh em sẽ gặp nó.

Giới hạn 30 request mỗi giây theo IP

Cũng theo tài liệu throttle, một IP gửi quá 30 request mỗi giây sẽ bị cắt request mới. Hành vi lúc bị cắt không được định nghĩa, nghĩa là anh em có thể nhận mã lỗi lạ hoặc kết nối bị đóng. API coi đây là hành vi lạm dụng nặng.

Script trong bài nghỉ 1 giây giữa hai trang. Tốc độ này thấp hơn ngưỡng ba mươi lần. Với nhu cầu đọc vài nghìn câu hỏi mỗi ngày, chạy chậm không làm tổng thời gian dài lên đáng kể.

Filter điều khiển trường trả về

Filter là chuỗi mã hóa danh sách trường muốn nhận. Filter có sẵn gồm default, withbody, none và total. Bài tài liệu filter mô tả cách tạo filter riêng để bỏ bớt trường.

Lab dùng filter total để đếm. Response chỉ nặng 13 byte, chứa {"total": 307}. Con số này cho biết tag python-requests và proxy có 307 câu hỏi tại thời điểm chạy. Biết tổng trước giúp anh em tính cần bao nhiêu request trước khi chạy thật.

Chuẩn bị truy vấn, ID và phiên bản khi dùng Stack Exchange API bằng Python

Phần này gom các quyết định cần chốt trước khi chạy: phiên bản API, tên site, cách viết tag, có cần key hay không và cách khóa môi trường Python.

Khóa phiên bản API trong URL

Phiên bản nằm ngay trong đường dẫn: /2.3/. Nên ghi phiên bản vào hằng số ở đầu script và ghi vào file kết quả. Khi API ra phiên bản mới, dữ liệu cũ vẫn truy được về đúng phiên bản đã sinh ra nó.

Endpoint /info cho biết thông tin site như tổng số câu hỏi và phiên bản API. Lab gọi /info qua proxy để kiểm tầng tải. Response nặng 404 byte, đủ nhẹ để làm request kiểm tra sức khỏe kết nối trước mỗi lần chạy.

Tên site và tag chính xác

Tham số site nhận tên ngắn như stackoverflow, superuser hoặc serverfault. Lab thử site=khong-co-site và nhận mã 400 với thông điệp No site found for name. Lỗi rõ ràng, không cần đoán.

Tag phải viết đúng như trên site, thường là chữ thường có gạch nối. Tag python-requests khác tag requests. Nên mở trang tag trên site để chép tên chính xác, rồi thử một request nhỏ xem total có hợp lý không.

Có cần app key hay access_token không

Không cần key để đọc dữ liệu công khai. Không có key, ứng dụng dùng chung quota theo IP với mọi ứng dụng khác trên cùng IP. Lab thấy quota_max là 300 cho trường hợp này.

Đăng ký app key trên Stack Apps nâng quota mặc định lên 10.000 request mỗi ngày theo tài liệu. Key không phải bí mật theo nghĩa mật khẩu, nhưng vẫn nên đọc từ biến môi trường. Bài này không đăng ký key, nên mọi số liệu là của chế độ ẩn danh.

Chuẩn bị môi trường Python

Lab chạy Python 3.12.10 trên Windows 10 với requests 2.34.2. Chỉ cần requests và thư viện chuẩn csv, json, time. PySocks được cài thêm để thử proxy SOCKS5, không cần cho luồng chính.

Nên ghi phiên bản thư viện vào requirements.txt. API trả JSON nén gzip, và requests tự giải nén. Lab ghi lại header Content-Encoding: gzip ở cả ba trang, nên kích thước byte trong bài là sau khi giải nén.

Đặt User-Agent mô tả ứng dụng

API không bắt buộc User-Agent riêng, nhưng nên đặt một chuỗi mô tả ứng dụng và cách liên hệ. Lab dùng ProxyVN-lab/1.0 với email giả [email protected]. Khi có sự cố, nhà vận hành biết request đến từ đâu.

Đừng giả User-Agent trình duyệt cho request API. API không cần, và việc đó chỉ làm log của anh em khó đọc hơn khi phải gỡ lỗi.

Viết truy vấn thành cấu hình

Gom site, tagged, sort, order và pagesize vào một dict cấu hình. Khi cần đổi tag, chỉ sửa cấu hình, không sửa vòng lặp. Cấu hình này cũng nên ghi vào đầu file kết quả để biết dữ liệu sinh ra từ truy vấn nào.

Thu dữ liệu có phân trang bằng Stack Exchange API bằng Python

Đây là phần chạy thật. Script đọc ba trang, ghi lại mã trạng thái, thời gian, quota và has_more sau mỗi trang, rồi xuất CSV.

Script lấy câu hỏi theo tag

90 câu hỏi, 0 trùng

Đoạn code dưới đây là bản rút gọn của script lab. Nó dừng khi has_more là false hoặc đủ số trang tối đa, và luôn đọc backoff trước khi gọi trang tiếp theo.

import csv, time, requests
B = "https://api.stackexchange.com/2.3/questions"
UA = {"User-Agent": "ProxyVN-lab/1.0 (lab@example.com)"}
cfg = {"site": "stackoverflow", "tagged": "python-requests;proxy",
       "sort": "creation", "order": "desc", "pagesize": 30}
rows, page = [], 1
while page <= 3:
    r = requests.get(B, params=dict(cfg, page=page), headers=UA, timeout=40)
    j = r.json()
    if r.status_code != 200:
        raise SystemExit(j.get("error_name"))
    for it in j["items"]:
        rows.append({k: it[k] for k in ("question_id", "title", "link", "score",
                     "answer_count", "is_answered", "creation_date")}
                    | {"tags": ";".join(it["tags"])})
    print(page, j["quota_remaining"], j["has_more"])
    if j.get("backoff"):
        time.sleep(j["backoff"])
    if not j["has_more"]:
        break
    page += 1
    time.sleep(1)

Kết quả ba trang

Bảng dưới là số đo thật ngày 29/10/2026. Thời gian là thời gian toàn request tính bằng giây, đo từ máy lab ở Việt Nam.

Bảng: Kết quả ba trang

Trang	Mã	Giây	Byte	Số câu	has_more	quota_remaining
1	200	0,866	21.863	30	true	294
2	200	0,759	21.614	30	true	293
3	200	0,742	21.479	30	true	292

Ba trang trả 90 câu hỏi, đủ 90 question_id khác nhau. Không có backoff ở trang nào. Mỗi trang giảm quota đúng một đơn vị, khớp với cách tài liệu mô tả.

Đọc has_more và tổng số

Sau trang 3, has_more vẫn là true, vì tổng là 307 câu hỏi. Muốn lấy hết với pagesize=30 cần 11 trang. Với pagesize=100 chỉ cần 4 trang. Lựa chọn này tiết kiệm bảy request quota cho cùng một kết quả.

Script lab giới hạn ba trang vì mục tiêu là đo, không phải lấy toàn bộ. Khi chạy thật, anh em thay điều kiện dừng bằng has_more và đặt thêm trần trang để tránh vòng lặp vô hạn nếu API trả sai.

Lỗi tham số và cách đọc

Hai lỗi lab gặp đều là 400 với JSON có error_id, error_name và error_message. Lỗi pagesize=101 mất 0,682 giây, lỗi site sai mất 0,675 giây. Cả hai vẫn tính quota, nên đừng để vòng lặp thử lại mù quáng với tham số sai.

Quy tắc đơn giản: lỗi 400 thì dừng và sửa cấu hình, lỗi 5xx thì chờ rồi thử lại có giới hạn, có backoff thì chờ đúng số giây. Bài rate limit API khi dùng proxy có thêm mẫu xử lý thử lại theo mã lỗi.

Sắp xếp theo creation để trang ổn định

Khi sort=activity, một câu hỏi vừa có câu trả lời mới sẽ nhảy lên đầu. Nếu điều đó xảy ra giữa lúc anh em đọc trang 1 và trang 2, một câu có thể xuất hiện hai lần hoặc bị bỏ sót.

Với sort=creation, câu mới chỉ chen vào đầu danh sách. Câu cũ dịch xuống, nên vẫn có thể trùng ở ranh giới trang, nhưng không bị mất. Lab đọc ba trang liên tiếp trong khoảng ba giây và không thấy trùng. Khi chạy lâu hơn, nên khử trùng theo question_id ở bước sau.

Lọc theo khoảng thời gian thay vì đọc hết

Tham số fromdate và todate nhận Unix timestamp. Chạy hàng ngày, anh em chỉ cần lấy câu hỏi tạo từ lần chạy trước tới giờ. Cách này giảm số trang xuống còn một hoặc hai, quota dư rất nhiều.

Nên lưu timestamp của lần chạy thành công gần nhất vào file. Lần sau đọc file đó làm fromdate. Nếu lần chạy lỗi giữa chừng, timestamp không đổi và lần sau sẽ lấy lại đúng khoảng bị lỡ.

Đối soát ID, kiểu dữ liệu, giá trị thiếu với Stack Exchange API bằng Python

Có dữ liệu rồi, bước tiếp theo là kiểm xem dữ liệu đúng chưa. Phần này liệt kê các phép kiểm lab đã chạy và các bẫy kiểu dữ liệu hay gặp.

question_id là khóa chính

Khóa chính site + ID

question_id là số nguyên duy nhất trong một site. Lab đếm 90 dòng và 90 ID khác nhau. Khi gộp dữ liệu nhiều ngày, khóa chính nên là cặp site và question_id, vì cùng một số ID có thể tồn tại ở hai site khác nhau.

Link câu hỏi chứa question_id và slug tiêu đề. Slug có thể đổi khi tiêu đề bị sửa, còn ID thì không. Vì vậy so sánh hai bản ghi nên dùng ID, chỉ dùng link để mở trang.

Ngày giờ là Unix timestamp

creation_date, last_activity_date và last_edit_date là số giây kể từ năm 1970 theo UTC. Câu hỏi đầu tiên trong lab có creation_date 1746013105. Đổi sang giờ Việt Nam phải cộng bảy tiếng sau khi chuyển về UTC.

Nên giữ cả số gốc lẫn chuỗi ISO trong file kết quả. Số gốc dùng để so sánh và lọc. Chuỗi ISO dùng để người đọc hiểu. Đừng chỉ lưu chuỗi đã đổi giờ địa phương, vì sau này rất khó biết đã cộng múi giờ hay chưa.

Trường có thể thiếu

Danh sách trường thô trong lab gồm answer_count, content_license, creation_date, is_answered, last_activity_date, last_edit_date, link, owner, question_id, score, tags, title và view_count. Trường last_edit_date chỉ có khi câu hỏi từng bị sửa.

Câu hỏi bị đóng có thêm closed_date và closed_reason. Câu hỏi có câu trả lời được chấp nhận có accepted_answer_id. Script nên dùng dict.get cho các trường tùy chọn, và ghi chuỗi rỗng thay vì để chương trình dừng vì KeyError.

Tiêu đề có ký tự HTML

Tiêu đề trả về đã mã hóa thực thể HTML. Dấu nháy có thể xuất hiện dưới dạng ' và dấu và thành &. Nếu ghi thẳng vào CSV rồi hiển thị trên web, người đọc sẽ thấy ký tự lạ.

Dùng html.unescape của thư viện chuẩn trước khi ghi. Nên làm việc này ở một bước riêng và ghi rõ trong mã, để người sau biết cột title đã được giải mã.

tags là danh sách

Trường tags là mảng chuỗi. Khi ghi CSV, lab nối bằng dấu chấm phẩy, khớp với cách tham số tagged nhận tag. Câu hỏi đầu tiên có ba tag python-requests, proxy và user-agent.

Nếu đưa vào cơ sở dữ liệu, nên tách tag ra bảng riêng với khóa câu hỏi. Cách này giúp đếm câu hỏi theo tag mà không phải tách chuỗi lại mỗi lần truy vấn.

Đối soát với total

Total 307 là số tại thời điểm gọi. Khi lấy hết, số dòng có thể lệch một vài câu vì có câu mới hoặc câu bị xóa giữa chừng. Lệch nhỏ là bình thường. Lệch lớn thường do điều kiện dừng sai hoặc lỗi ở giữa vòng lặp.

Nên ghi số total, số dòng nhận được và số ID khác nhau vào một file nhật ký. Ba con số này đủ để biết lần chạy có đáng tin không mà không cần mở dữ liệu.

Giữ xuất xứ cho từng dòng

Mỗi dòng nên có link gốc, thời điểm lấy và phiên bản API. Lab xuất file 282_questions.csv gồm question_id, title, link, score, answer_count, is_answered, creation_date, last_activity_date và tags. Khối owner bị bỏ có chủ đích.

Bài JSON và CSV khi crawl dữ liệu bàn khi nào nên lưu JSON thô song song với CSV. Với API này, giữ JSON thô của từng trang giúp tái lập kết quả khi cần kiểm tra lại.

Lưu kết quả, giới hạn request và khi nào Stack Exchange API bằng Python cần proxy

Phần cuối trả lời câu hỏi anh em hay hỏi nhất: có cần proxy không. Câu trả lời ngắn là hiếm khi cần, và proxy không bao giờ là cách tăng quota.

Lưu CSV và JSON thô

CSV tiện mở bằng bảng tính và chia sẻ. JSON thô giữ đủ trường, kể cả trường script chưa dùng tới. Lưu cả hai theo ngày giúp anh em so sánh hai lần chạy và tái lập kết quả khi tài liệu API thay đổi.

Đặt tên file theo ngày và truy vấn, ví dụ questions_python-requests_proxy_2026-10-29.csv. Đừng ghi đè file cũ. Dung lượng mỗi file chỉ vài chục KB, nên giữ lịch sử không tốn bao nhiêu.

Quota tính theo IP và proxy không đổi điều đó theo cách anh em muốn

Không có key, quota là của IP. Nếu chạy qua proxy, quota tính cho IP thoát của proxy, không còn là IP máy anh em. Với proxy dùng chung, IP thoát đó có thể đã bị người khác tiêu quota từ trước.

Đổi qua nhiều IP để cộng dồn quota là đi ngược chính sách throttle. Cách đúng khi cần nhiều hơn 300 request mỗi ngày là đăng ký app key để có 10.000 request. Key gắn với ứng dụng, đi theo anh em dù chạy ở mạng nào.

Lab đặt proxy ở tầng tải

Lab chạy một proxy HTTP có xác thực và một proxy SOCKS5 cục bộ, rồi gọi /info qua từng loại. Proxy HTTP nhận lệnh CONNECT tới api.stackexchange.com:443. Proxy SOCKS5 nhận tên miền api.stackexchange.com, kiểu địa chỉ domain, cổng 443.

Bảng: Lab đặt proxy ở tầng tải

Cách gọi	Kết quả	Giây	Proxy thấy gì
Proxy HTTP, đúng mật khẩu	200	0,781	CONNECT api.stackexchange.com:443
SOCKS5h, đúng mật khẩu	200	0,782	Tên miền, cổng 443
Proxy HTTP, sai mật khẩu	ProxyError	0,022	auth_ok false, không có request tới API

Hai điều rút ra. Proxy chỉ thấy tên máy và cổng, không thấy tham số truy vấn vì HTTPS mã hóa phần còn lại. Lỗi xác thực proxy dừng ở proxy, API không nhận request nào, nên không tốn quota.

Khi nào proxy thật sự có ích

Proxy có ích khi mạng công ty bắt buộc đi qua proxy để ra Internet. Nó cũng có ích khi máy chủ nằm ở vùng mạng bị chặn kết nối ra ngoài, hoặc khi cần một IP thoát cố định cho danh sách cho phép nội bộ. Cả ba trường hợp đều là chuyện đường đi, không phải chuyện quota.

Nếu cấu hình proxy trong requests, bài cài đặt proxy cho thư viện requests có đủ cách khai báo. Mật khẩu có ký tự đặc biệt cần mã hóa URL. Lab dùng mật khẩu chứa @ và #, và phải mã hóa thành %40 và %23 mới chạy được.

Khi hệ thống của anh em cần một IP thoát cố định để đưa vào danh sách cho phép, proxy tĩnh dễ quản lý hơn proxy xoay. ProxyVN có proxy dân cư tĩnh, datacenter, 4G và proxy xoay, hỗ trợ HTTP và SOCKS5. Anh em có thể mua proxy tại trang chủ ProxyVN rồi khai báo vào tham số proxies của requests như trong lab.

Giới hạn suy luận của bài

Mọi số đo là của một máy ở Việt Nam, chạy ngày 29/10/2026, không có app key. Thời gian request phụ thuộc mạng và giờ chạy. Quota 300 là con số API trả về cho IP lab tại thời điểm đó, có thể khác ở IP khác hoặc khi chính sách thay đổi.

Lab chưa gặp backoff, chưa gặp lỗi 429 hay lỗi do vượt 30 request mỗi giây, vì cố ý không gửi nhanh. Proxy trong lab là proxy cục bộ, chưa thử với proxy thương mại. Hành vi khi IP thoát dùng chung đã hết quota chưa được đo.

Checklist Stack Exchange API bằng Python

Checklist Stack Exchange API

• Chốt site, tag, sort và order trong một dict cấu hình.
• Đặt pagesize=100 khi cần lấy nhiều để tiết kiệm quota.
• Đọc has_more để dừng, đặt thêm trần số trang.
• Luôn đọc backoff và chờ đủ số giây.
• Giữ dưới 30 request mỗi giây, tốt nhất là một request mỗi giây.
• Bỏ khối owner nếu không cần thông tin người dùng.
• Giải mã thực thể HTML trong tiêu đề trước khi hiển thị.
• Khóa chính là cặp site và question_id.
• Cần nhiều quota thì đăng ký app key, không đổi IP.

Câu hỏi thường gặp về Stack Exchange API bằng Python

Không có key thì lấy được bao nhiêu request mỗi ngày?

Lab thấy quota_max là 300 cho request không có key. Quota này dùng chung với mọi ứng dụng khác trên cùng IP. Có app key thì quota mặc định là 10.000 theo tài liệu throttle.

Có lấy được email người hỏi không?

Không. API công khai không trả email, và bài này khuyên không tìm cách lấy. Bảng câu hỏi chỉ cần ID, tiêu đề, link và tag.

Vì sao quota_remaining không bắt đầu từ 300?

Vì quota tính theo IP trong ngày. Nếu cùng IP đã gửi request trước đó, dù từ script khác, quota đã bị trừ. Lab bắt đầu ở 294 vì đã có vài request trước.

Có nên dùng thư viện bọc sẵn thay vì requests?

Có thể, nếu thư viện còn được bảo trì và hỗ trợ API 2.3. Viết bằng requests giúp anh em thấy rõ wrapper, quota và backoff, nên dễ gỡ lỗi hơn khi API thay đổi.

Proxy có giúp tránh bị cắt khi gửi quá 30 request mỗi giây không?

Không nên dùng proxy cho mục đích đó. Ngưỡng 30 request mỗi giây là giới hạn chống lạm dụng. Giảm tốc độ là cách đúng.

Lấy câu trả lời thì dùng endpoint nào?

Dùng /questions/{ids}/answers với tối đa 100 ID mỗi lần. Cách này tiết kiệm quota hơn gọi từng câu hỏi một.

Stack Exchange API bằng Python và những điều cần nhớ

Stack Exchange API bằng Python cho anh em bảng câu hỏi theo tag mà không cần tải HTML. Lab ngày 29/10/2026 lấy 90 câu hỏi không trùng qua ba trang, mỗi trang tốn một đơn vị quota, quota ẩn danh là 300 mỗi ngày. Đọc has_more, tôn trọng backoff, bỏ dữ liệu cá nhân và đăng ký key khi cần nhiều hơn. Cần IP thoát cố định cho hệ thống chạy Stack Exchange API bằng Python, liên hệ Proxy.vn - Nhà cung cấp dịch vụ proxy chất lượng hàng đầu Việt Nam.