从“上帝”视角看后端接口如何设计

这里先说说“上帝”是什么？上帝，是移动端，pc端，h5端的统称，为什么这么说呢，接口设计的最终目标，是让用户可以正常使用软硬件提供的服务。用户使用不同的端来访问接口，从而与后端发生关联关系，进而使用相关的服务。

而这些端的开发者，他们将界面与接口进行有效的结合形成一个个有机体，不同的有机体组合形成一套系统，他们使用接口，他们是顾客（自家的接口免费用，别人的接口限制或者付费用），而顾客是什么？是上帝，因此，作为“上帝”之一的移动端，有必要聊聊接口设计的东西，尽管有可能以下内容会对后端开发人员造成不适感，也要勇敢说出来。另外，也算是对接口设计思考与认知的总结。欢迎各位看官小伙伴提出一些看法，一起进步。

接口设计规范

基本性

基本性是指，接口地址符合一般性URL所具有的要素。

1.请求path

栗子

这里，以获取商品详情信息，get请求，如下：
http://www.xxx.com/Goods/getGoodsInfo?id=10025

http:是网络协议部分，该部分规定数据交互遵守的统一标准。
     现实中，可以是https，还可以是ftp或者rtmp等
xxx.com:是域名部分，该部分域名访问时，需要进行地址映射，域名->ip地址
     现实中，既可以是域名，也可以是ip地址（尤其调试阶段，各种ip地址，毕竟后端人员多，各个对接）
path：Goods/getGoodsInfo?id=10025（斜体加粗部分）
Goods:是后端功能模块，不同的功能模块，这部分对应内容有所不同。如，User信息模块，/user/getUserInfo
getGoodsInfo：是模块功能中某一具体功能对应的action（前端）或者method（后端），这里指获取商品信息的方法
    ?id=10025：？是一个特殊的分隔符，用于获取其后携带的参数，id为参数

在真实项目中，形似上述接口可能有很多，大家在使用这些接口时也习以为常，毕竟接口能正常走通。不过，不知道小伙伴们有没有发现不太合理的地方？暂且先留个问题，继续往下看

path设计原则

1.见名知意 好的path设计，使用者（开发人员或者测试人员）看到接口时，就可以很清楚的了解接口对应的功能。上述的栗子，在一定程度反映了对应的功能。以常见一些功能为栗，如下：

method	Path	含义	栗子	具体说明
GET	getXxxx	查找或者查询	getUserInfo	获取用户信息
POST	addXxxx	提交或者增加	addOrder	增加新订单
POST	modifyXxxx	修改或者更新	modifyUserInfo	修改用户信息
POST	deleteXxxx	删除	deleteAddress	删除地址

这样可以减少不必要的沟通成本，记得，该沟通时一定要沟通，毕竟不是所有的设计都是那么规范。你走过的路不一定是别人的套路，有可能是血路，用同感吗？

总结，一句话，当看到接口时ÿ