接口由谁来设计更妥当

近日，看了篇文章，名为《一篇来自前端同学对后端接口的吐槽》，阅后，颇有感触。

在文中，这个槽吐得犀利，甚合吾意。作者开篇就抛出了自己的观点：究竟接口应该由谁来设计？是接口的消费者，还是接口的提供者？消费者就是使用并展现接口数据的前端人员，对应的提供者则是后端人员。

通常接口的定义是由后端人员来设计，这样建库、建表也方便，一条路就走下去了。设计完之后呢，就丢给前端去用，后端不用，就如文中提到的“好比一个从来不尝自己做的菜的厨子，你指望他的菜能好到哪里去，他的厨艺能好到哪里去？”，这就很有可能导致设计出来的接口不好用。

我待过的都是小公司，大公司的情况是什么样，没待过，不清楚，没有发言权。做为一个小公司，我们没有架构师，接口也都是由后端的哥们设计，因为老板认为由后端人员来设计接口，项目有保障，前端的人员不懂后台，不能设计；做为我们前端也认为，前端设计出来的接口字段还得要后端来实现，不知对后端的数据结构有什么影响，是不是数据库不好架构，表是不是不好设计，到时候，实现不了也是白费。因此，由后端来设计接口也是件水到渠成的事儿。

由提供者设计接口其实没有什么不妥，只要你别站在开发者的角度来想问题。

在实际项目中调用接口时，我的体会是太难用了，接口里什么数据都有。获取文章的信息，连作者的用户信息都有，而且信息还非常之全，什么用户的创建时间、用户的权限标识、用户名的修改时间......，不光这样，获取的文章信息里，还有几个空字段，都是数据库里预留的。看起来，接口数据要嘛有嘛，可前端从接口中抽取的有用信息，经常都不到一半，造成了极大的带宽浪费。我只要小而美，你给我弄了个大而全。

相比大而全，更煎熬的是，接口返回的数据，你前端不能直接用，得二次加工。用一个for循环，根据某个字段id，把获取的数据全部或部分地筛选一遍，重新组织出一个新数据集来，最终展现的是这个新数据集，而不是接口给的数据。

有时，在另外一个场景需要数据时，提供者会跟你说：“你调之前那个接口就行，里边有数据，你自己摘一下。”

累啊，而且这种情形还经常在你眼前出现。

最后，借用文中作者的话做个总结吧：“API和代码应该是精准的，准确表达你想实现的一切而不存在有歧义。一个接口本应该就专注一件事情。”