前后通讯规范

作为一个全栈工程师，从移动端到后台，我觉得有必要说道一下前后的通讯，双方使用同样的规范，会保证开发过程中比较顺利。

首先，我们用的是http协议或者是https协议，其实这两种协议从访问者角度来讲，并无太大的区别，特别是从客户端来讲，请求自己的服务器，并不需要刻意验证https证书的有效。这里不展开说明

其次，通讯的规则必须是服务端定的，因为服务端是作为服务进行发布，客户端进行访问。但这不代表服务端可以随便使用，需要考虑到照顾不同的请求方式。

对于一个访问接口，我们会有四个部分内容
一、请求协议
二、资源名称
三、参数
四、返回内容

我们对这四个部分做规定

一、请求协议

请求协议使用http，关于http可以详见
https://blog.csdn.net/u010256388/article/details/68491509/

请求头对照表：
http://tools.jb51.net/table/http_header

在这里，说一下请求头。请求头一般是不需要设置的，因为底层通讯的时候已经帮助我们做了。但是还是需要注意几点

1、可接受的响应内容类型（Content-Types）

我们需要规定好响应内容类型，最常见的就是 text/html。但是这属于页面内容，给到浏览器解析HTML使用。默认的也就是text/html。但是需要注意，iOS的AFN网络框架并没有把text/html 作为标准进行数据解析。虽然这个地方不设置也可以得到数据，但并不是规范的方式。建议使用 application/json 的方式。
同时，也注意在此设置内容的编码方式，客户端读取到后，根据这里规定的编码方式去解析内容。
这里也不是设置为application/json后就万事大吉，而是需要根据资源类型，设置不同的type

附：content-type 对照表

2、跨域响应头部

这里一般是ajax请求方式会有的问题，当页面服务与数据服务不在同一个域下面，会有数据访问不通的问题。移动端不会有此问题。
跨域需要响应头设置：

//表明允许跨域访问
Access-Control-Allow-Origin:上面origin的地址

参考：https://blog.csdn.net/c5113620/article/details/79132047

3、请求方式method

我们常见的就是get与post，这两种请求方式已经满足了大多数的场景。需要强调一下，我们最好按照最小需要的方式去设置。很多时候开发者懒得去指定请求的方式，所以会所有的方式都可用，如get与post的请求都可以得到数据。这并不是一种好的方式，不要嫌麻烦，我们指定好请求的方式，特别是对那些重要的内容

二 、资源名称

这里的资源名称，就是请求访问的路径。一万个人心里有一万个Url的命名规则，Url是统一资源定位符，重点是资源。
现在提倡使用RESTful API，一种清爽，简洁的方式
http://www.ruanyifeng.com/blog/2018/10/restful-api-best-practices.html
https://blog.csdn.net/qq_21383435/article/details/80032375
但这也不是绝对的解决方案

优点是因为他对uri进行了限制，只用于定义资源。这样看起来比较容易理解。尤其是对简单的对象的增删改查，很好理解。

缺点是因为这种限制，导致设计uri变得复杂了。尤其是复杂的关系，操作，资源集合，硬性套用rest原则设计非常困难。在rest基础上的HATEOAS，返回的json里增加了相应的关系和url。这也同样带来问题。好处是对简单的关系，的确可以通过url进一步处理。但对复杂的关系和操作，HATEOAS并不能胜任描述。反而在单纯的数据中增加了一堆垃圾信息。

三、参数

参数的设置一般是有两种方式
1、使用json方式
2、使用get方式
一般是post使用第一种方式，把参数放到请求体内；get请求使用第二种方式，直接拼接到url中。
其实这种说法不是很准确，应该说是我们的http请求内容有url部分，请求头，请求体。
url部分：在url中，我们可以在 "?"符号后面添加参数，这也是我们常见的get请求带参方式。但是同样的，其他请求方式也是可以采用此方法携带参数，这样也增加了灵活性。

请求头：在上面说到有请求头的设置，这里请求头也可以携带参数到服务器，并进行解析。常见会有用户信息认证，放到请求体内觉得格格不入，放到url中还不是很靠谱，就放到了请求头中。还有App和手机的信息，例如操作系统版本、机型、App版本等等，我们也会放到请求头中

请求体：请求体中可以放置我们的数据。请求体内的数据其实并无特定的规定，但是为了方便解析，还是需要对格式作以规定。同时，我们需要在请求头内说明，请求体的内容是什么。一般的，我们会使用键值对的形式去传递参数，对于大多数情况下，这种方式是足够的。但是对于复杂数据，这种方式就会有些捉襟见肘。我们也可以按照json的方式去处理，后台需要做好json的解析。

四、返回内容

1、捕获所有异常

对于接口而言，需要保证健壮性和稳定性。不能够有500等这种的错误，不管什么情况下，都要返回标准的数据形式。这样客户端才会方便处理，只需要判断返回码就可以。客户端请求的error也只是网络原因，而不是服务器崩溃信息。

2、返回内容

返回内容需要包含以下几个方面

1）、返回码 code

返回码表明操作的状态，我们可以按照http错误码的方式定义，200表示成功。也可以按照自定义的方式，比如0表示成功。当然我们可以定义4位到6位的返回码，采用有含义码的编码方式，定义错误码。比如第一位4开头表示无权限，第二三位表示操作，第五六位表示具体类型。
关于命名来讲，有使用code的，也有使用status的。这个就看使用者的想法了。不过在一个项目中，不能出现两种命名。

2）、返回信息 message

返回文字描述的错误信息，这里也可以是在国际化文件中去定义，针对不同语言返回不同的的内容。或者根据请求参数里面携带的语言信息判断也可以。这里的返回信息也主要是给客户端提示的消息。若客户端自行处理提示消息，那么返回信息也可以省略。
返回信息一般是对错误的描述，错误时一般不会有返回的data数据，那么把返回信息放到data内也是可以的。关于命名，有使用message的，也有使用info的。不过还是说，一个项目内，都采用同一种处理方式，不能出现两种以上方式。

3）、返回内容 data

这里就是具体的返回内容。比如请求一个列表，列表信息就可以放到这里。如果是有分页信息，也是放到这个里面，不要放到跟这个同级的节点里。放到根节点一是返回内容要单独处理，不能够统一处理信息；二是客户端处理的时候，判断错误码后不能直接单独的取数据解析或者转换成对象，增加了处理的复杂度。

安全方面

作为数据接口来讲，我们不能采用session的方式去维护有效与验证。我们可以在参数上下功夫。参考聚合数据的api，可以发现，所有的请求都会要求携带AppID。前后交互时我们也可以这样处理。不过如果是专门的抓包，这也并不能避免身份的伪造。我们只能对传输内容加密，在过程中拦截的数据都是无效数据。加解密规则是服务端与客户端共同知道。