聊一聊写 REST 接口时的一些比较烦人的问题

1. 其实最主要的一个问题就是查询接口的数据拼接问题。比如说一个博客的系统，查询一条博客信息，不仅要返回博客信息，还要去拼接上作者的信息。这样会定义一大堆数据组合类。然后查询逻辑里面有大量的数据组合代码。（有时可能会有三层到四层，而且有时是需要去其他服务去取数据）。例如下面的代码示例

class BlogModel {
    String authorUserID;
    ...
}

class BlogDomain extends BlogModel {
    private UserInfo authorInfo;
}

// 读取 BlogModel，然后去用户服务根据用户 ID 去取用户信息，最终拼接成 BlogDomain 返回
List<BlogDomain> getBlogList(int start, int limit) {
    List<BlogModel> blogModelList = dao.query(start, limit);
    
    // 批量去取
    Set<String> authorUserIDs = blogModelList.stream()
    		.map(BlogModel::getAuthorUserID)
            .collect(Collectors.toSet());
    Map<String, UserInfo> authorUserInfoMap = Collections.emptyMap();
    if (!auditUserIDs.isEmpty()) {
        authorUserIDs = userService.select(authorUserIDs);
    }
    
    return blogModelList.stream().map(blogModel -> {
        BlogDomain blogDomain = new BlogDomain();
        BeanUtils.copyProperties(blogModel, blogDomain);
        blogDoamin.setAuthorInfo(authorUserInfoMap.get(blogModel.getAuthorUserID()));
        return blogDomain;
    }).collect(Collectors.toList());
}

1. REST 响应根据 HTTP 状态码作为错误码是不够的，一般接口还会再定义一个自定义的错误码（我看即使那些 GG,FB,INS,Twitter 的 API 文档也是这么玩的）。如果有了自定义的错误码，其实那个 HTTP 状态码实际显得有些鸡肋，唯一的作用就是使服务端和客户端的编码逻辑稍微变得更加复杂。

2. 文档，现在用的最主要的文档工具就是 Swagger/OpenAPI，但是实际上会发现，无论是 code 自动生成文档，还是文档生成 code(客户端还好，主要是服务端，生成的 code 基本上没法用)都不好用。最后还是自己的手写文档。这样工作量又多了一些。

光这些问题，就让编码过程变得很烦了，也许可能需要一个能代替现有方式的东西。比如，GraphQL，gRPC 或者其他的东西。