数据|是什么让我放弃了Restful API？后端|rest|前端|

点击上方 "程序员小乐"关注, 星标或置顶一起成长
每天凌晨00点00分, 第一时间与你相约
每日英文
Good friends are like stars. You don’t always see them, but you know they’re always there.
好朋友就像是星星。你不一定总是能见到他们，但你知道，他们会一直在那里。
每日掏心话
生活是开水，不论冷热，只要适合的温度，生活是口味，不论酸甜苦辣，只要适合的口感，就是最好。
来自：IT研究僧大师兄 | 责编：乐乐
链接：toutiao.com/i6833818331884028419

文章图片
程序员小乐(ID:study_tech)第 935 次推文图源：百度
往日回顾：面试官问我：Java反射是什么？我回答竟然不上来......

正文
背景REST作为一种现代网络应用非常流行的软件架构风格，自从Roy Fielding博士在2000年他的博士论文中提出来到现在已经有了20年的历史。它的简单易用性，可扩展性，伸缩性受到广大Web开发者的喜爱。

文章图片
REST 的 API 配合JSON格式的数据交换，使得前后端分离、数据交互变得非常容易，而且也已经成为了目前Web领域最受欢迎的软件架构设计模式。

文章图片
但随着REST API的流行和发展，它的缺点也暴露了出来：

滥用REST接口，导致大量相似度很高（具有重复性）的API越来越冗余。
对于前端而言：REST API粒度较粗，难以一次性符合前端的数据要求，前端需要分多次请求接口数据。增加了前端人员的工作量。
对于后端而言：前端需要的数据往往在不同的地方具有相似性，但却又不同，比如针对同样的用户信息，有的地方只需要用户简要信息（比如头像、昵称），有些地方需要详细的信息，这就需要开发不同的接口来满足这些需求。当这样的相似但又不同的地方多的时候，就需要开发更多的接口来满足前端的需要。增加了后端开发人员的工作量和重复度。

那我们来分析一下，当前端需求变化，涉及到改动旧需求时，会有以下这些情况：
做加法：
产品需求增加，页面需要增加功能，数据也就相应的要增加显示，那么REST接口也需要做增加，这种无可厚非。
做减法：
产品需求减少，页面需要减少功能，或者减少某些信息显示，那么数据就要做减法。
一种通常懒惰的做法是，前端不与后端沟通，仅在前端对数据选择性显示。
因为后端接口能够满足数据需要，仅仅是在做显示的时候对数据进行了选择性显示，但接口的数据是存在冗余的，这种情况一个是存在数据泄露风险，另外就是数据量过大时造成网络流量过大，页面加载缓慢，用户流量费白白消耗，用户体验就会下降。
另外一种做法就是告知后端，要么开发新的接口，要么，修改旧接口，删掉冗余字段。
但一般来说，开发新接口往往是后端开发人员会选择的方案，因为这个方案对现有系统的影响最低，不会有额外的风险。
修改旧接口删除冗余数据的方案往往开发人员不会选择，这是为什么呢？
这就涉及到了系统的稳定性问题了，旧接口往往不止是一个地方在用，很有可能很多页面、设置不同客户端、不同服务都调用了这个接口获取数据，不做详细的调查，是不可能知道到底旧接口被调用了多少次，一旦改动旧接口，涉及范围可能非常大，往往会引起其他地方出现崩溃。改动旧接口成本太高，所以往往不会被采取。关注公众号程序员小乐回复关键字“offer”获取算法面试题和答案。
同时做加减法：
既有加法，又有减法，其实这种就跟新需求没啥区别，前端需要重做页面，后端需要新写接口满足前端需要，但是旧接口还是不能轻举妄动（除非确定只有这一处调用才可以删除）。
往往这个时候，其实用到的数据大多都是来自于同一个DO或者DTO，不过是在REST接口组装数据时，用不同的VO来封装不同字段，或者，使用同样的VO，组装数据时做删减。
看到这些问题是不是觉得令人头大？

文章图片
所以需求频繁改动是万恶之源，当产品小哥哥改动需求时，程序员小哥哥可能正提着铁锹赶来……

文章图片
那么有没有一种方案或者框架，可以使得在用到同一个领域模型（DO或者DTO）的数据时，前端对于这个模型的数据字段需求的改动，后端可以根据前端的改动和需要，自动适配，自动组装需要的字段，返回给前端呢？如果能这样做的话，那么后端程序猿小哥可能要开心死了，前端妹子也不用那么苦口婆心地劝说后端小哥哥了。
所以GraphQL隆重出世了！
GraphQL简介