接口定义

Question

一个后端系统,随着业务的发展,发现对外提供的接口越来越多,这个时候应该怎么去优化呢,WEB服务还好,但是如果是纯粹的API调用,怎么去用少量的API满足大量需求,可否用范型对外提供API

Answer 1

告诉你大公司的api是什么样子的: 
微信支付接口: https://pay.weixin.qq.com/wiki/doc/api/app/app.php?chapter=9_1
对外API接口: 它就是公司对别人的承诺, 永远不要要求对方改变调用参数, 你可以扩展内容, 但你不能让以前的实现不能使用.所以最灵活的API接口就是: 象java 的main方法一样永远不会改变, 但每个人使用时参数都不一样.微信, 支付宝, 他们的接口也就是 20来个方法,  他每一个接口都很灵活. 
我发现他们有一个特点: 参数只有一个文本, 文本的内容可以是XML, 也可以是JOSN字符, 可以无限扩展参数, 但是接口定义永远不需要改变!!

Answer 2

/**  微信统一下单接口
     * 作用：统一下单<br>
     * 场景：公共号支付、扫码支付、APP支付
     * @param reqData 向wxpay post的请求数据
     * @return API返回数据
     * @throws Exception
     */
    public String unifiedOrder(String  reqData) throws Exception ;

Answer 3

我比较支持这样的方式, 定义接口时什么也不要想: 输入字符串, 返回字符串, 只要定义接口的名称就是了!//插入数据
public String insertData(String  reqData) throws Exception ;//查询数据
public String queryData(String  reqData) throws Exception ;//删除数据
public String deleteData(String  reqData) throws Exception ;//修改数据
public String updateData(String  reqData) throws Exception ;以后都是云时代, 参数越简单才越通用.

Answer 4

试试 restful 规范

Answer 5

上个月一狠心把人全拉上，下线了40%的接口，维护成本降低了很多很多：1、一定要严格按照restful来;2、能扩展和复用绝不新增；3、还有就是要会撕，不能别人要什么就给什么，现有接口组合能完成的尽量也别新增（以性能能够接受为前提）。

Answer 6

个人赞同你的观点,对外服务一般不会变,第三方也不会接受你的改变,但是如果初期定义的太差,后面会导致内部实现逻辑越来越复杂,比如说一个支付系统内部,肯定有很多的模块,有的模块可能会提供dubbo服务,专门用来做某个领域的处理,有的模块可能这个时候初期定义接口就比较重要,其实不管是支付宝接口还是微信接口,一般都会遵循一定的规范,他问什么要这么去这样定义这些接口

Answer 7

这个你得有很大的权威,如果纯粹的restful,那如果有一个业务需求涉及到10个表,那是否需要别人调用10次,不知道我这样理解restful是不是有问题??

Answer 8

个人赞同你的观点,对外服务一般不会变,第三方也不会接受你的改变,但是如果初期定义的太差,后面会导致内部实现逻辑越来越复杂,比如说一个支付系统内部,肯定有很多的模块,有的模块可能会提供dubbo服务,专门用来做某个领域的处理,有的模块可能这个时候初期定义接口就比较重要,其实不管是支付宝接口还是微信接口,一般都会遵循一定的规范,他问什么要这么去这样定义这些接口虽然参数只有一个, 不管是用:
public String unifiedOrder(String  reqData) throws Exception ;
还是用
public Map<String, String> unifiedOrder(Map<String, String> reqData) throws Exception ;
你作为接口定义人, 肯定要对  reqData进行定义.比如, 查询订单接口参数:
<xml>
   <appid>wx2421b1c4370ec43b</appid>
   <mch_id>10000100</mch_id>
   <nonce_str>ec2316275641faa3aacf3cc599e8730f</nonce_str>
   <transaction_id>1008450740201411110005820873</transaction_id>
   <sign>FDD167FAA73459FD921B144BAF4F4CA2</sign>
</xml>XML里面的内容是有严格说明的:
应用APPID      appid 是 String(32) wxd678efh567hg6787 微信开放平台审核通过的应用APPID
商户号        mch_id 是 String(32) 1230000109 微信支付分配的商户号
微信订单号      transaction_id 是, String(32) 1009660380201506130728806387 微信的订单号，优先使用这就是规范.

Answer 9

对内和对外的取舍不一样,对外的接口自然越少越好,减少开发者学习成本,比如微信支付宝这种
对内的话,多个接口可以隔离逻辑,多个URL是利用框架层面的路由,你在参数中设置类型,那是你自己写代码路由,这其实也算一种逻辑重复,美团下单的参数自然跟共享单车下单的参数可能完全不一样,参数反序列化部分也与框架提供的功能重叠
简单来说你的下单接口分担了框架的职责(反序列化和路由),这与其他接口的风格略有不一致当然我说的是缺点,那自然也有优点,优点就不多说了

Answer 10

当前微服务盛行的情况下，各服务只有自己领域内的数据，
必然存在前端要调用多次后端接口的情况。我们的实现方式：
前端包括2块：纯前端（H5）+nodejs网关层（也算服务端，只是前端在维护）
后端提供基础数据的完整接口网关层调用n个后端接口，把数据做简单组合，一次性返回给前端。
一定要避免前端调n个后端接口，弱网会哭的。

Answer 11

框架总会过时, 依赖框架一就折腾自己. 产口注定会失败. 当框架不流行时, 你的产品只能被抛弃.
真正的不变的东西是业务与管理. 接口是定义业务与管理, 不是根据网上的各种框架来适应. 
中国人开发软件都喜欢搞什么 框架 现在国内除了几个大电商, 所有做软件的公司 基本都是倒闭状态.
国内公司没有核心, 都喜欢依赖国外的东西. 
以前大家都搞 soap web service, 现在又搞 restful,  其实都只是技术实现 与接口定义没有毛关系.

Answer 12

做接口定义核心是业务与管理, 清楚的业务与核心管理方式, 才能清楚定义出标准接口.
对于实现技术, 只需要了解即可, 知道实现技术的根本差别就可以了.
比如: web service 接口 与 restful风格接口, 差别在几点:
1, restful 参数是文本, web service 参数也可以是文本, 这一点两种技术不冲突.
2, web service 可以是实体对象, restful 没有这种方式.
3, web service 依赖专用框架, restful  依赖公用框架
4, web service 接口 与  restful 可以做到互通 没有影响.因此 公司定义出接口, 应当是达到几点: 
1, 没有系统平台限制
2, 没有技术实现限制
3, 简单, 并且可读性好.定义文档出来之后, 用 web service 还是用  restful又有什么影响? 完全没有影响, 想用什么技术就用什么技术实现!!
依赖框架只有一个结果: 把自己框死.

Answer 13

提醒, 搞了多年java, 我们开发组都是写了文档再开发的: 按照文档开发, 接口都是大家讨论好在文档中定义的, 大家签字后就开工, 
至于用什么技术实现, 公司什么产品就用什么技术, 每个产品技术都有点不同. 但是接口都是一份.
我们有 5-8套系统, 这些系统之前都要是交互的, 有些用java做的, 有些用c++写的, 有些用.net写的.  如果按技术去定义接口那不完了?
虽然中间也有反复修改, 都修改了文档再开发代码.
国内有几家公司可以做到: 先写文档再开发程序? 

Answer 14

不赞同最后一句话，至少我呆过的几个公司都是先写文档，然后对着文档在开发，其中有些比较详细的，可能完全照着文档写下来没bug。