api接口类型有哪些-按实际调用场景划分适配业务需求

前段时间对接第三方支付系统，被新来的实习生当场问住api接口类型有哪些，那一刻才意识到自己写了两年接口代码，一直凭手感调用，从来没系统捋过分类，每次对接新项目都是凭旧经验瞎套，好几次都因为接口类型选错导致对接超时、数据丢失，返工熬了好几个通宵。

最开始的认知特别浅薄，一直固执的认为接口就只有HTTP协议下的GET和POST两种，平时做前端数据查询就用GET，提交表单、传复杂数据就用POST，压根没考虑过还有其他适配不同业务的接口类型。上次做即时消息推送功能，死活用POST接口反复请求数据，页面一直卡顿、响应延迟严重，反复排查参数、校验请求头，折腾大半天都找不到问题，后台日志全是无效的重复请求，测试那边直接打回了版本，说实时数据刷新完全达不到用户使用需求，白白浪费了大半天的开发时间。

后来才反应过来，实时场景根本不适合HTTP接口。

慢慢翻项目往期的迭代记录，才发现公司项目里一直混用着多种接口类型，只是自己从来没刻意区分、也没主动深究过。除了大众最熟知的HTTP接口，还有专门做实时双向通信的WebSocket接口，做微服务系统内部数据交互的RPC接口，还有用来传输大容量文件、批量数据的FTP接口，这些类型对应的使用场景完全不重叠，乱套用只会徒增bug和服务器压力。

上次对接物流轨迹同步的需求，一开始偷懒想用普通HTTP接口定时拉取数据，每隔十秒请求一次后台接口，不仅服务器压力暴增，还经常出现数据更新不及时、轨迹断层、重复展示旧数据的情况，运营那边收到了好多客户的投诉反馈。折腾好久才搞明白，这种需要持续双向传输、高频更新数据的业务，绝对不能用短连接的HTTP接口，必须用WebSocket接口，它不用反复建立和断开连接，一次长连接就能持续双向通信，实时推送最新的轨迹数据，改完之后服务器负载直接降了大半，数据同步延迟的问题也彻底解决了。

RPC接口的用处也很特殊。

平时做微服务拆分后的项目，不同服务之间的内部调用，用HTTP接口就会显得冗余又低效，参数解析繁琐、传输速度慢，还存在大量多余的请求头、响应头消耗资源。而RPC接口是专门针对服务内部高频通信设计的，传输效率更高、稳定性更强，不用处理多余的网页请求参数，只专注于服务之间的数据交互，这也是很多大型微服务架构项目都会优先用它的原因，我之前不懂这些区别，所有接口调用统一用HTTP模板，导致整个项目的运行效率一直偏低，上线后还出现过服务超时拥堵的问题。

还有小众但刚需的FTP接口，几乎只用来做文件批量传输。日常的表单数据、json格式数据交互完全用不到它，但如果是批量上传用户归档资料、同步服务器日志文件、传输高清素材包，它的传输稳定性和速度，是普通HTTP接口完全比不了的。之前试过用HTTP接口批量传输上千条文件数据，直接出现大面积丢包、报错中断，换成FTP接口之后，一次性就对接成功，批量传输的成功率直接拉满。

做开发久了才发现，接口类型从来不是靠死记硬背区分的，所有分类都是为了适配不同的业务场景，没有绝对的好坏，只有合不合适。那天改完所有接口适配问题，下班收拾键盘的时候，顺手删掉了项目里所有乱用的通用HTTP请求模板。