大背景
现在软件设计业务流程都是协作合作的，前后端分立，所以他们怎样同时实现对 API 的标准化知觉？又该怎样结构设计两个较好的 API USB？随著销售业务的重构，怎样结构设计两个有相容性的API？面对多种应用程序，怎样结构设计两个时时适用于的 API 呢？
RESTful 是目前最流行的 API 结构导则，透过一定的规范化能解决上面那些难题，对于 RESTful 构架的理解能参照阮志成同学的这首诗（
http://www.ruanyifeng.com/blog/2011/09/restful.html），单纯一句话是对伺服器端天然资源展开操作形式，同时实现”表现层状况转化”。URI（标准化天然资源功能定位符）代表一类天然资源，它能是一段文档、一张图片、一首歌曲目、一类服务项目；五种天然资源相关联两个某一的 URI，存在着此种相关联关系。怎样的 API 是好的结构设计呢？
他们要遵从以下几个准则：
技术标准RESTful API 透过 GET POST PUT DELETE 等形式对伺服器的天然资源展开操作形式，因此在表述 API 的时候须要明确表述出：允诺形式、版、天然资源中文名称和天然资源ID，文件格式如： GET http://{host}/{version}/{resources}/{resource_id}，如查阅采用者代码为1 的采用者信息 GET /v1/users/1。
技术标准主要从 URL 结构设计、状况码的采用、伺服器积极响应码采用，具体内容可参照阮志成同学的RESTful API 最差课堂教学（
https://www.ruanyifeng.com/blog/2018/10/restful-api-best-practices.html），一千万不要自表述状况码。 相容性随著销售业务的发展，结构设计一下有相容性的 API 是非常重要的，如果USB不能够相容，销售业务就会受到很大影响，产品囊括 Android iOS PC 等应用程序，采用者须要技术升级到最新的版，才能更快地采用，此种情况下导入版的概念，同时实现 API 的相容性。能参照许多对外开放 API 的结构设计，透过版号或许多控制器模块来支持许多新功能。
抽象化性USB抽象化都是如前所述销售业务需求，表述明晰的销售业务难题域数学模型，并建立起和某一难题的相关联，同时实现抽象化，能较好地过滤具体内容的销售业务同时实现技术细节，提供更快的扩展性。
单纯性严格遵守最多科学知识准则，是应用程序，不须要知道所以多服务项目的 API USB，以及那些 API USB的调用技术细节，如外观USB对各个微服务项目标准化管理（展开销售业务封装与整合），对调用方提供两个单纯的 API ，应用程序只须要调用两个USB，而不用关心里面的技术细节。
高性能外观USB虽然保证了单纯性，但是增加了服务项目端的销售业务复杂度，多服务项目之间的聚合，导致USB性能不好，还要考虑入参字段的各种组合，会不会导致数据库的性能难题，有时候他们暴露了过多字段给外部组合采用，有可能导致数据库没有相应的索引，而发生全表扫描，因此，他们只提供存在索引的字段组合，给外部调用，要求索引字段为必填字段，这样保障能正常采用索引来确保性能
幂等性幂等性（Idempotent）在这里表示发送一次和多次允诺引起的边界效应是一致的。如在网速不够快的情况下，应用程序发送两个允诺后没有立即得到响应，由于不能确定是否允诺是否被成功提交，所以有可能会再次发送另两个相同的允诺，幂等性决定了第二个允诺是否有效。
HTTP 7种方法中的（GET、HEAD 和 OPTIONS）均是幂等方法。由于 DELETE 和 PATCH 允诺操作形式的是现有的某一天然资源，所以它们是幂等方法。对于 PUT 允诺，只有在相关联天然资源不存在的情况下伺服器才会展开添加操作形式，否则只作修改操作形式，对于是否幂等操作形式，还要看这个修改操作形式是相对的还是绝对的，比如更新年龄，是在原值的基础上加1操作形式，还是更新成两个新的年龄了。至于最后一类 POST，由于它总是展开添加操作形式，如果伺服器接收到两次相同的 POST 操作形式，将导致两个相同的天然资源被创建，所以这是两个非幂等的方法。
怎么解决幂等性难题呢？（单纯场景：表单重复提交）利用 Redisson 同时实现分布式锁，并防止重复提交。这个话题能单独写一首歌诗总结一下。
安全性对于提供公网域名展开访问，而且USB和关键销售业务有关，所以安全性很重要。安全措施大体来看主要在两个方面，一方面是怎样保证数据在传输过程中的安全性，另两个方面是数据已经到达伺服器端，伺服器端怎样识别数据，以及怎样不被攻击。
数据加密数采用 https 协议，在 http 和 tcp 之间添加一层加密层(SSL层)，这一层负责数据的加密和解密。
数据加签数据加签是由发送者产生一段无法伪造的一段数字串，来保证数据在传输过程中不被篡改，服务项目端透过验证这个签名来判断是否合法允诺。
时间戳机制经过如上的加密，加签处理，就算拿到数据也不能看到真实的数据，但是有不法者直接拿到抓取的数据包展开恶意允诺；这时候能采用时间戳机制，在每次允诺中加入当前的时间，伺服器端会拿到当前时间和消息中的时间验证，看看是否在两个固定的时间范围内，这样恶意允诺的数据包是无法更改里面时间的，所以超过这个时间范围就视为非法允诺。
AppId 机制对外提供的USB其实也ss_token。
限流机制本来是真实的采用者，并且开通了 AppId，但是出现频繁调用USB的情况，此种情况须要给相关 AppId 限流处理，常用的限流算法有令牌桶和漏桶算法。
黑名单机制如果此 AppId 展开过很多非法操作形式，经过分析之后直接将此 AppId 列入黑名单，所有允诺直接返回错误码。
数据合法性校验只有在数据是合法的情况下才会展开数据处理；每个USB都要有验证规则，当然也可能有许多常规性的规则，比如身份证长度和组成，电话号码长度和组成等等。
总结
本文大致列举了几种 API 结构设计常见的准则：技术标准、相容性、抽象化性、单纯性、高性能、幂等性、安全性，其中安全措施机制包括：数据加密、数据加签、时间戳机制、AppId 机制、限流机制、黑名单机制以及数据合法性校验。当然肯定有其他形式，欢迎补充。
