使用json-server测试POST接口时如何更新指定用户的books数组

json-server的原生路由仅匹配db.json内的顶层独立资源，你之前尝试请求的/users/books路径，会被json-server识别为“查询id值为'books'的用户条目”，既不是合法的嵌套资源更新接口，也没有对应的数据匹配逻辑，因此必然触发报错。
由于你的数据结构中，books是单个用户对象下的嵌套属性，并非顶层独立资源，原生json-server不支持直接对嵌套属性发起POST类型的更新操作。

方案一：基于原生json-server能力完成更新（无需额外配置，适合快速测试） #

整个流程完全适配已知目标用户id的场景，分三步执行：

• 先拉取目标用户的现有完整数据
  发起GET请求到/users/[已知的目标用户id]，拿到包含当前books数组的完整用户对象。
  示例：给id为1的用户新增书籍时，先请求GET http://localhost:3000/users/1
• 本地组装更新后的books数组
  把新提交的书籍信息追加到拉取到的现有books数组中，不要覆盖原有书籍数据。
• 向对应用户的路由发起更新请求
  可以选择两种符合json-server规范的请求方法：
  • 用PATCH方法请求/users/[目标用户id]，请求体只需要传入更新后的books数组即可，无需提交用户的全量信息
    示例请求格式：

    PATCH /users/1 HTTP/1.1
    Host: localhost:3000
    Content-Type: application/json
    
    {
      "books": [
        {"bookName": "《React设计模式与实践》", "price": 89},
        {"bookName": "新增的测试书籍", "price": 59}
      ]
    }
    

  • 用PUT方法请求同样的用户路由，需要传入组装完成的完整用户对象，保证原有用户的name、email等字段不丢失。

方案二：自定义路由模拟嵌套接口（适配更贴近真实业务的测试场景） #

如果想直接实现POST /users/[id]/books这种业务常用的嵌套提交接口，可以在json-server启动时挂载简单的自定义中间件，拦截对应路径的请求：

• 拦截匹配POST /users/:userId/books的请求
• 根据路径中的userId找到db.json里对应用户条目
• 把请求体里的书籍信息追加到该用户的books数组末尾
• 将更新后的用户对象写回db.json，返回更新后的最新用户数据
  这种方式可以完全匹配真实业务的接口调用习惯，不需要在前端逻辑里额外先拉一次用户数据再组装请求。

• 不要把books作为顶层资源单独写入db.json，否则会破坏已有的用户-书籍关联数据结构
• 发起请求时必须把请求头的Content-Type设置为application/json，否则json-server无法正确解析请求体内容
• 不要直接向/users发起POST请求，否则会新建一条全新的用户条目，完全达不到更新现有用户books数组的目的

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