路由命名规范请求方式请求WEB端请求参数加密处理(组图)

发布时间:2021-06-08 来源: 万汇智联 浏览次数:

概述

本文分享API接口设计规范,目的是为开发者提供参考。

法规已死,而人们还活着。我希望他们不会被自己的规定打败。

路由命名约定

api接口设计规范

api接口设计规范

请求方法

api接口设计规范

api接口设计规范

请求参数查询

后面的参数

网址?存储请求接口的参数数据。

标题

请求头中存储了公共参数、requestId、token、加密字段等。

身体

Body body,存放请求接口的参数数据。

常用参数

APP 请求

api接口设计规范

api接口设计规范

网页端请求

api接口设计规范

api接口设计规范

调用者需要向服务器申请appKey(请求时使用)和secretKey(加密时使用)。

安全规定

敏感参数的加密处理

登录密码和支付密码传输前需要加密。建议使用非对称加密。

其他标准返回参数

api接口设计规范

api接口设计规范

如果返回分页数据,格式如下:

{
    "code": 1,
    "showMsg": "success",
    "errorMsg": "",
    "data": {
        "list": [],
        "pagination": {
            "total": 100,
            "currentPage": 1,
            "prePageCount": 10
        }
    }
}

安全规定

敏感数据脱敏

用户手机号、用户邮箱、身份证号、支付账号、邮寄地址等必须脱敏,部分数据会带*处理。

其他标准签名设计

签名验证没有明确的规范。你可以自己制作。可以选择使用对称加密、非对称加密、单向哈希加密等,并分享原始签名验证以供参考。

日志平台有利于故障定位和日志统计分析。

ELK 组件可用于搭建日志平台。使用Logstash收集日志文件,使用Elasticsearch引擎进行搜索分析,最终展示在Kibana平台上。

幂等设计

不能保证每次调用接口都会返回结果,必须考虑网络异常的发生。

例如,创建订单时,我们需要减少库存。这时候接口已经超时,调用者重试。库存会不会再扣一次?

这种类型的问题有两种解决方案:

一、 服务方提供相应的查询接口。调用方在请求超时后执行查询。如果找到,则说明请求处理成功。如果没有找到,就会经历失败的过程。

二、 调用者只是再试一次,服务器保证一次多次请求的结果相同。

对于第二种方案,服务器接口需要支持幂等性。

总体设计思路是这样的:

调用接口前,先获取一个全局唯一的令牌(Token)。调用接口时,将Token放入Header头api接口设计规范,解析Header头,验证是否为有效Token。如果无效,直接返回失败。完成业务逻辑后api接口设计规范,设置业务结果与Token关联存储。设置过期时间时不要重新获取Token并重试。使用最后一个Token总结

限流设计、熔断设计、降级设计,这些就不多说了,因为大部分都没用。使用的时候,这些功能基本都是加在网关上的。

暂时想到这么多。规范不是静态的。如果发现调整不当,及时调整。

你的界面的输入输出键,你是用驼峰命名还是下划线命名?欢迎留言。

上一篇:移动互联网的api设计(1)(2)

下一篇:没有了

上一篇:移动互联网的api设计(1)(2)

下一篇:没有了