Ruby循环调用API分批拉取全量用户数据的实现方法

核心逻辑说明 #

该接口属于标准偏移量分页模式，不需要做页码换算，直接按已拉取数据长度累加offset即可，通用逻辑可适配任意总条数的拉取场景，核心流程如下：

• 首次请求携带count=true参数，拿到全量用户总计数，作为循环终止的核心判断依据
• 固定单次拉取条数为接口支持的最大值250，初始偏移量设为0
• 每完成一次拉取，先对当前批次的用户数据做自定义属性赋值，再存入全量结果集，之后将偏移量累加250
• 当偏移量大于等于总用户数时终止循环，额外增加「当前批次返回条数小于250直接终止」的兜底判断，避免接口返回总计数不准导致死循环

可直接复用的代码 #

require 'faraday' # 可替换为项目内常用的HTTP客户端，比如Net::HTTP、HTTParty
require 'json'

# 基础配置，替换为实际业务参数
BASE_URL = '替换为实际接口域名'
ACCOUNT_ID = '替换为路径参数中的账号ID'
SINGLE_FETCH_LIMIT = 250

def fetch_all_users
  conn = Faraday.new(url: BASE_URL) do |f|
    f.response :json # 自动解析JSON格式响应
    f.adapter Faraday.default_adapter
    # 可在此处添加通用鉴权逻辑，比如Token、Cookie请求头
    # f.headers['Authorization'] = "Bearer #{your_access_token}"
  end

  all_users = []
  offset = 0
  total_count = nil

  loop do
    # 构造请求参数，首次请求带count=true拿总数，后续请求可不带该参数减少响应体积
    request_params = {
      limit: SINGLE_FETCH_LIMIT,
      offset: offset,
      count: total_count.nil?
    }

    response = conn.get("/accounts/#{ACCOUNT_ID}/users", request_params)
    raise "接口请求失败，状态码：#{response.status}" unless response.success?

    # 首次请求时解析总条数，需根据实际接口返回结构调整取值位置
    # 部分接口会把总数放在响应头X-Total-Count中，部分放在响应体的total字段
    if total_count.nil?
      total_count = response.body['total'] # 若总条数在响应头则改为 response.headers['x-total-count'].to_i
    end

    # 按实际接口返回结构调整用户列表的取值key
    current_batch_users = response.body['data']
    break if current_batch_users.nil? || current_batch_users.empty?

    # 在此处编写当前批次用户的属性赋值逻辑
    current_batch_users.each do |user|
      # 示例：给每个用户添加拉取批次、所属账号ID属性，可替换为实际业务需要的赋值逻辑
      user['fetch_batch'] = offset / SINGLE_FETCH_LIMIT + 1
      user['belong_account_id'] = ACCOUNT_ID
    end

    all_users.concat(current_batch_users)
    offset += SINGLE_FETCH_LIMIT

    # 双重终止判断：偏移量超过总条数/当前批次条数小于单页上限，避免死循环
    break if offset >= total_count || current_batch_users.size < SINGLE_FETCH_LIMIT
  end

  all_users
end

# 调用方法获取全量用户
all_users = fetch_all_users
puts "全量拉取完成，共获取#{all_users.size}条用户记录"

注意事项 #

• 代码中标注的总条数字段、用户列表字段取值位置，需要根据对接接口的实际响应结构调整，不要直接硬抄
• 如果接口有流控限制，可以在每次循环请求前加sleep间隔，避免触发频控被拦截
• 生产环境使用建议增加请求重试逻辑，针对网络超时、5xx类错误重试当前offset的请求2-3次，避免中途拉取失败导致数据不全
• 不要把offset换算成页码计算，严格按照已拉取条数累加offset，完全匹配接口要求的「记录数偏移」规则

内容的提问来源于stack exchange，提问作者born2Learn