API开放平台如何设计【学习笔记】

API开放平台如何设计【学习笔记】

本文基于Java平台，主要讨论的问题是【API开放平台如何设计】

前期思考

随着平台业务的增大，或者基于业务属性，业务平台需要向第三方开发者提供一些接口，以便于用户能通过程序来调用平台的功能，此时，就需要设计一个高可用的API管理平台。用户可以通过登录平台，通过权限配置，来申请接口的使用，平台接口提供方，需要对这些接口提供浏览和调用。调用方式可以直接以HTTP或SDK的形式让用户基于他自己的系统进行集成。接口的每次调用都需要进行记录，平台统计接口的相关调用情况，诸如调用频次、相应时间、来源进行分析优化。平台管理方可以发布、下线、禁用接口，并通过版本的管理，对接口进行升级。

如非必要，不要随意把接口对外进行开放，否则容易被DDOS！介于此，所以平台需要注意到这里的接口管理，需要更多的安全考虑和随时可以进行下线以及禁用，这里对接口的管理颗粒度可以尽可能的小，比如IP、设备类型、用户ID等，具体的处理需要结合平台业务发展来考虑。

需要考虑如下几个问题：

1.访问权限，用户是否可以随意访问数据库和接口

2.是否需要通过计费的方式来自动阻塞用户接口的调用

3.禁用、下线、升级接口的具体场景设计需要考虑清楚，避免接口被盗刷

将从如下几点来探讨这个问题

1、接口设计

2、性能及其可用性

3、安全

4、数据跟踪以及流量控制

5、用户交互

接口设计

开放平台的接口应该需要考虑到实际的场景、业务。

原子性：明确接口的业务边界，不要搞万能接口，增删改查，有几种就给几种，不要图方便去搞一些诸如查不到就创建的这种接口，会造成业务的不可控，以及脏数据

业务属性：要考虑是否必须要开放这个接口，且开放的接口不要与系统内部接口使用同样的路由（遇到过把系统内部使用的接口直接开放出去，然后服务被各种花式吊打）

事务：保持最终一致性吧，要不然有得玩，并发场景下尤其需要注意

幂等：使用相同参数多次调用同一接口，产生的结果和单次调用需要一致，要不然会有扯皮

文档完整性：写的文档要尽量清晰，一般会在平台提供模拟接口页面去供用户进行接口调试，如果不想浪费这个资源，也应该给出完整的测试代码，避免扯皮

其他的诸如数据加密、隐私、字段管理、数据返回格式、接口返回格式等需要根据实际平台进行设计。这里不做讨论

性能及其可用性

对外提供的接口 9999999 想要调用方不打爆你的客服电话，就老老实实强化下性能，一个中间件不行，就上俩。上下游调用问题会导致信用问题。

安全

一般使用申请、鉴权认证的方式来进行基础的安全初始化，针对某一客户，如果没有得到相关的权限，就不要轻易给他开放接口，你永远不会知道客户会怎么使用你的平台

申请：注意颗粒度，一般是账号级别，涉及平台有子账号的情况，可以考虑大包小，或者直接到最小账号级别，这个看实际场景

鉴权认证：加密算法尽量自定义，公开的内容容易被开盒，不要轻易去尝试，涉及利益，需要谨慎！

阻断方案：例如禁用、下线、升级维护，需要做好通知，一旦开始有用户使用了，就不要轻易的停用服务

数据跟踪以及流量控制

日志：对于调用日志，尽可能详细，大规模的调用记录下详细的日志，便于审计和业务分析

链路跟踪：尽可能有详细的链路记录去对调用负责，便于排查问题以及甩锅

流量控制：及时做好服务扩/缩容，成本考量在此声明

用户交互

管理端：尽可能提供全面的管理页面，对于接口的权限管理、数据分析会有很大的帮助，且尽量提供二次确认，避免误操作。大部分云厂商的API服务管理，例如网关、负载均衡、DNS会有缓存处理，如果误操作了，可能会导致服务一时半会儿无法恢复，得不偿失

用户端：主要的接口、统计、费用管理需要明细，容易被咨询的地方需要写明细，很多人是不看文档的，这里可以在接口的测试用例里去明确，避免产生二次沟通

 

 

 

未完待续··· 将以Spring Boot、Spring Cloud以及各种中间件来讲一个实例