pip install flask

# 导入框架from flask import Flask, request, jsonify# 初始化应用app = Flask(__name__)# 1. GET接口：查询数据（浏览器/地址栏直接访问）@app.route("/api/user", methods=["GET"])defget_user():    # 获取URL传参：?name=张三    name = request.args.get("name","默认用户")    # 构造返回数据（标准JSON格式）    res ={          "code":200,# 状态码：200成功          "msg":"查询成功",          "data":{                  "username": name,                  "age":25          }    }    return jsonify(res)# 返回JSON# 2. POST接口：提交数据（表单/JSON传参）@app.route("/api/add", methods=["POST"])defadd_data():    # 接收前端传的JSON参数    req_data = request.get_json()    num1 = req_data.get("num1",0)    num2 = req_data.get("num2",0)    result = num1 + num2    return jsonify({        "code":200,        "msg":"计算完成",        "result": result    })# 启动服务if __name__ =="__main__":    app.run(host="0.0.0.0", port=5000, debug=True)

1. 执行代码，服务启动在 http://127.0.0.1:5000

​

1. 测试 POST 接口：Postman访问http://127.0.0.1:5000/api/add，请求体传 JSON：

{"num1":10,"num2":20}

1. 请求方式区分

• 查询数据 → GET
• 新增、提交表单 → POST
• 修改数据 → PUT
• 删除数据 → DELETE
  


2. 参数传递方式

• GET：参数拼在 URL 后面 ?key=value
• POST/PUT：主流用 JSON 请求体
  
  

3. 统一返回格式（团队通用）所有接口返回结构保持一致，方便前端解析：

   {"code":200,// 状态码：200成功、500服务异常、404地址不存在"msg":"提示信息","data":{}// 业务数据（成功时返回）}

4. 接口命名：

1. Postman / ApiFox：本地调试 GET/POST 接口
2. FastAPI/SpringBoot 自带文档：在线直接调试
3. 浏览器：仅能测试 GET 接口
   
   

• 自己写接口：上面示例，后端开发，提供地址给别人调用

• 调用别人接口：用代码发 HTTP 请求（requests/HttpClient），不属于 “写接口”

在接口对接时，经常听到双方讨论是我把数据推给你，还是你主动来取，这两个有什么区别吗？改用哪一种？下面进行详细介绍。

• 逻辑：我方提供查询接口，对方主动定时 / 按需调用接口，把数据拿走。
• 举例：我开放 /api/get_data，对方每隔 1 分钟 / 每次业务操作，主动请求拉取最新数据。
  
  

• 逻辑：数据产生 / 更新后，我方主动调用对方提供的接收接口，把数据发过去。
• 举例：你提供接收地址 /api/receive，我这边数据一变，立刻 POST 数据发给你。
  
  

1. 我方实现简单、风险低：只写一个查询接口即可，不用管对方状态。
2. 对方自主可控：想什么时候取、取多少由自己决定。
3. 容错好：对方网络/服务挂了，晚一点再来取就行，不用我方维护重试。
   
   

1. 实时性差：轮询间隔越大，数据延迟越高；间隔太小又会产生大量无效请求。
2. 我方服务器被频繁访问，流量、并发压力高。
   
   

• 对实时性要求不高（报表、基础档案、统计数据）
• 数据更新频率低
• 对接方技术弱、不愿额外开发接口
• 数据量大，对方需要分批 / 分页拉取
  
  

1. 实时性极强，数据变更马上同步。
2. 无效请求少，整体网络开销更小。
   
   

1. 我方逻辑复杂：要做重试机制、失败日志、防重复推送、超时处理。
2. 依赖对方接口稳定性：对方服务挂了，我方推送就失败。
3. 对方需要额外开发接收接口。
   
   

• 高实时性需求（订单、消息、状态变更、支付结果）
• 数据更新频繁
• 希望减少无效请求、节约服务器资源
  
  

• 实时性无所谓，延迟几秒 / 几分钟都能接受
• 想少写代码、少担责任
• 对方不想开发新接口
• 数据是全量 / 大列表，适合分页查询
  
  

2. 优先选【推模式】的情况

• 必须实时同步（订单、告警、状态回调、支付通知）
• 不希望大量轮询压垮接口
• 数据变动频率高，但每次数据体量小
  
  

1. 推拉结合（最稳）

• 初始全量：对方拉取历史 / 全量数据
• 后续增量：我方推送新增 / 变更数据
  企业对接最常用，兼顾完整 + 实时。
  
  

2. 推送失败兜底：推送失败后，对方定时拉取做补偿。

阅读原文：https://mp.weixin.qq.com/s/SjZ46biHJWs_P1jU28rFJw