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

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

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());
}

REST 响应根据 HTTP 状态码作为错误码是不够的，一般接口还会再定义一个自定义的错误码（我看即使那些 GG,FB,INS,Twitter 的 API 文档也是这么玩的）。如果有了自定义的错误码，其实那个 HTTP 状态码实际显得有些鸡肋，唯一的作用就是使服务端和客户端的编码逻辑稍微变得更加复杂。
文档，现在用的最主要的文档工具就是 Swagger/OpenAPI，但是实际上会发现，无论是 code 自动生成文档，还是文档生成 code(客户端还好，主要是服务端，生成的 code 基本上没法用)都不好用。最后还是自己的手写文档。这样工作量又多了一些。

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

leon0903

2019-04-24 21:21:56 +08:00

1. 我一直觉得 rest 返回码不如自定义返回码，自定义返回码可以携带很多信息。要是我主导项目，我肯定不会首选 rest。
2. 文档感觉 swagger 已经不错了啊，现在我们这把就是用的 swagger，然后甩给前段。
lz 代码里面体现的问题我也确实经常遇到，感觉没什么好的办法，你这还好是 java 8，可以用 stream，其实简化了不少了。我用 go 开发这样的，都没办法，只能一次一次的遍历。。。