接口方案设计（接口的设计）

本文目录一览：

• 1、API接口安全设计方案（已实现）

• 2、为什么 USB 接口设计之初选择了不能正反插的方案？

• 3、怎么写 App 接口设计方案

• 4、一个页面请求多个接口的设计方案

• 5、接口设计怎么写？

API接口安全设计方案（已实现）

网络安全方案，主要从数据加密与api接口安全两个方面考虑，数据加密https已经加密了，就不再次加密了；主要从api安全方面考虑。

在代码层面，对接口进行安全设计

一、使用token进行用户身份认证

二、使用sign防止传入参数被篡改

三、用时间戳防止暴力请求

用户身份认证的流程图如下：

具体说明如下：

1、 用户登录时，客户端请求接口，传入用户名和密文的密码

2、 后台服务对用户身份进行验证。若验证失败，则返回错误结果；若验证通过，则生成一个随机不重复的token，并将其存储在redis中，设置一个过期时间。

其中，redis的key为token，value为验证通过后获得的用户信息

3、 用户身份校验通过后，后台服务将生成的token返回客户端。

客户端请求后续其他接口时，需要带上这个token。后台服务会统一拦截接口请求，进行token有效性校验，并从中获取用户信息，供后续业务逻辑使用

为了防止中间人攻击（客户端发来的请求被第三方拦截篡改），引入参数的签名机制。

具体步骤如下：

1、客户端和服务端约定一个加密算法（或MD5摘要也可）， 客户端发起请求时，将所有的非空参数按升序拼在一起，通过加密算法形成一个sign，将其放在请求头中传递给后端服务。

2、后端服务统一拦截接口请求，用接收到的非可空参数根据约定好的规则进行加密，和传入的sign值进行比较。若一致则予以放行，不一致则拒绝请求。

由于中间人不知道加密方法，也就不能伪造一个有效的sign。从而防止了中间人对请求参数的篡改。

sign机制可以防止参数被篡改，但无法防dos攻击（第三方使用正确的参数，不停请求服务器，使之无法正常提供服务）。因此，还需要引入时间戳机制。

具体的操作为：客户端在形成sign值时，除了使用所有参数和token外，再加一个发起请求时的时间戳。即

sign值来源 = 所有非空参数升序排序+token+timestamp

而后端则需要根据当前时间和sign值的时间戳进行比较，差值超过一段时间则不予放行。

若要求不高，则客户端和服务端可以仅仅使用精确到秒或分钟的时间戳，据此形成sign值来校验有效性。这样可以使一秒或一分钟内的请求是有效的。

若要求较高，则还需要约定一个解密算法，使后端服务可以从sign值中解析出发起请求的时间戳。

总结后的流程图如下：

这里还是隐藏下了。

规则：sha1(keyvalkeyval+token+timestamp+id)

例如：sha1（address33bussinessType22city111companyNamest232ringtokentimestampid）

这里新增一个id值，与token对应，传输过程中不使用，只用于加密，保证数据即使被截获，因为请求中没有id的传输，更加安全。

token身份认证；

timestamp方式防止dos攻击，防止重放，简单说就是一次接口调用，只能用一定时间，比如比对时间，60s内该次调用有效，60秒后失效；

sign签名，通过参数+token+timestamp+id固定位加密，保证参数不会被修改，调用有效；

为什么 USB 接口设计之初选择了不能正反插的方案？

因为它主要是方便计算机和外置设备连接而设计的。接口在推出之后被迅速推广到其他设备上，为它们提供数据传输、供电功能，同时也延伸出不少自带 USB 口的设备。

虽然，USB-A 口的出现为我们带来不少方便。但大家其实也发现，绝大部分的 USB-A 接口是不能同时兼容正插和反插。

要是设备放在一些空间比较狭窄的地方，人不方便判断接口的正反向时，要将数据线接到接口上就变成了一件很麻烦的事。幸好，现在也推出了能兼容正反插的 USB-C 口和 Lightning 接口，用起来也更方便一些。

针对 USB-A 接口不能同时兼容正反插这个问题，USB 接口的联合开发者 Ajay Bhatt 就在与 NPR 的访问中做了解释。他表示，USB-A 没有用上正反插兼容的设计主要还是跟成本有关。

根据 The Verge 的报道，Bhatt 在设计这种通用接口的时候做过很多尝试。他希望这个接口能够兼容绝大部分的设备，也同时要要足够简单。他在接受 PC World 的访问时就用一个简单的例子来说明他的设计用意：

当年我们做这个接口的时候，就是希望它能够解决 90 年代的线缆连接问题。以前的插头和连接器太多了，很复杂，人们用起来其实并不方便。我是希望能有一个接口，可以帮助一般的家庭能快速把计算机和打印机连接起来，并且能够打印他们需要的东西。只要这个接口足够方便，他们接上就会用，同时也不需要每次都打电话来向我求助，那我觉得这样的接口就足够。

的确，USB-A 的出现为不少设备的连接提供便利性。它不仅能够用于简单的数据传输和供电，自带处理功能的设备也可以通过 USB 接口连接外置储存设备，并直接播放里面的内容。

例如，现在有不少汽车里面都附带了一个 USB 接口，车主只需要把 U 盘接进去就能直接播放歌曲。对比起还要自己改造车内播放设备的以前，这样的设计确实方便不少。

不过，Bhatt 也在访问中提到这种 USB 接口时遇到的问题，那就是接口的正反插兼容设计和成本之间的问题：

要让 USB 接口做到正反插都能兼容，其实并不容易。如果要用上这种设计，那就必须在 USB 接口上嵌入多一倍的电线和电路，那成本也必定要翻倍。

Bhatt 还提到，他们也考虑过方便盲插的圆形接口。但同样也因为成本的问题，最终也未能采用圆形接口的方案。

毕竟，通用接口还是要以普及为主要目标，要是在功能没有太大差距但却要付出更多的成本，那厂商和用户自然也不会接受。所以，Bhatt 在这里选择也正确的，他为 USB-A 挑选了成本更低也能保持方便的方案，也为这个接口带来了普及的机会。

和 USB-A 比起来，USB-C 口体积更小，功能集成度和性能都要比 USB-A 要高，设备通过一个 USB-C 口就可以完成供电、数据传输、显示传输等多个功能。

怎么写 App 接口设计方案

private function loaderHandler(event:*):void {

switch(event.type) {

case Event.COMPLETE:

trace(_loader.data.result);

break;

case Event.OPEN:

trace("open: " + event);

break;

case ProgressEvent.PROGRESS:

trace("progress: " + event);

break;

一个页面请求多个接口的设计方案

在一个页面可能会有请求多个接口的情况，而接口的请求是异步的，为了能保证一个页面数据的同步处理，针对多个异步线程的处理建议使用信号量机制，在异步线程开始前将信号量加1，线程执行完成后再把信号量减1，然后通过线程的汇总，在信号量为0的时候执行页面数据的处理操作。

信号量的加减操作有两种：

第一种：

自定义一个信号量dispatch_semaphore_t，一般默认初始化的信号量值是0.

信号量加1：

信号量减1：

第二种：

创建线程组dispatch_group_t，对线程组进行信号量的加减操作

信号量加1：

信号量减1：

接口设计怎么写？

接口设计包括三个方面：一、用户接口用来说明将向用户提供的命令和它们的语法结构，以及软件的回答信息。二、外部接口用来说明本系统同外界的所有接口的安排包括软件与硬件之间的接口、本系统与各支持软件之间的接口关系。三、内部接口用来说明本系统之内的各个系统元素之间的接口的安排

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。