别把游戏 API 按渲染或引擎分，看接入形态更靠谱：本地 SDK 与远程 Web API 双层解析
游戏 API 类型区分基于接入形态与功能对象双层逻辑，先分本地 SDK 与远程 Web API，再按用户身份、网络通信及内容服务等具体对象归纳。
为什么“渲染”或“引擎”不是游戏 API 的分类标准？
渲染技术或游戏引擎并非游戏 API 的通用分类标准，因现有官方文档未提供统一架构对比，且同一技术栈常承载完全不同的业务逻辑。
常有人把游戏接口按”DirectX 渲染”或”Unity 引擎”来划分，但这套说法在现有文档里其实找不到依据。翻开 Steamworks 或 RAWG 的官方索引，里面没有 DirectX、Vulkan、OpenGL 或 Unity 的架构对比图，也没有任何文档将接口强行归入这些技术框架 [1][2]。现有的材料只记录了接口如何被调用，却没解释程序如何进入底层硬件或引擎内部。如果你试图用“渲染接口”或“引擎接口”去概括所有情况，会发现同一功能可能跨越不同技术栈，而同一技术栈又承载完全不同的业务逻辑。
这种分类方式不仅缺乏行业通用的强制标准，更会导致实际开发场景的描述混乱。它无法回答“这个接口是调用了显卡驱动还是访问了用户数据”这类具体问题。直接套用技术框架名称，就像拿着地图找路，却忘了看脚下的地形。真正的分类应当基于程序与服务的连接方式，而非背后的技术实现细节 [3][4]。
这里存在一个极易被误解的盲区：许多开发者认为“图形 API（如 Direct3D）”属于游戏服务接口的一部分，但实际上它们处于完全不同的层级。图形 API 负责的是像素如何在屏幕上绘制，属于底层的渲染管线；而我们讨论的游戏 API（如登录、存档、排行榜）关注的是业务逻辑与平台服务的交互。即便你的游戏是用 Unity 开发的，当你调用 SteamAPI_Init() 时，你实际上是在请求一个网络或本地库的服务，而不是在指挥显卡画图。混淆这两者，往往会导致在排查问题时方向完全错误——比如把网络连接超时误判为图形渲染卡顿。因此，真正的分类界限在于：你的代码是跑在本地机器上，还是通过网络去够远处的服务。
第一层标准：按接入形态区分本地 SDK 与远程 Web API
游戏接口第一层分类依据程序接入形态，将直接嵌入构建环境的本地代码库与依赖网络请求的远程服务明确划分为本地 SDK 与 Web API。
你能直接调用的代码库，和需要跨网络发送的请求，构成了游戏接口的第一道分水岭。这种分类不看功能是什么，只看程序如何“进门”。现有证据显示，最稳妥的划分方式是依据接入形态：一边是嵌入本地的 SDK，另一边是依赖网络的 Web 服务 [1][2]。
本地 SDK 如何嵌入游戏运行环境
本地 SDK API 像是一套预制的零件，直接塞进你的构建流程里。它由库文件、头文件和运行时组件构成，编译时链接，运行时加载 [3]。以 Steamworks SDK 为例，开发者在打包游戏前，必须将这些二进制文件集成到项目目录中 [1]。这种方式下，调用过程发生在进程内部，无需经过外部网络握手，响应速度取决于本地内存读写效率。它适合处理那些对延迟敏感、需要深度绑定引擎底层的操作。
远程 Web API 的网络交互机制
远程 Web API 则完全依赖 HTTP 协议。程序不携带任何本地逻辑，只需构造一个请求，发送给平台服务器或第三方数据源，等待返回 JSON 或 XML 数据包 [4]。Steamworks Web API 允许你在浏览器或后台脚本中查询玩家成就，RAWG API 则负责聚合全球游戏元数据 [2]。这种模式解耦了游戏本体与服务端，但代价是必须处理网络波动、鉴权失败等外部变量。
两种形态的交叉关系
同一项功能往往能同时通过这两种形态实现。比如获取用户信息，既可以通过本地 SDK 直接读取，也能通过 Web API 拉取。它们不是互斥选项，而是针对不同场景的接入方案。下表展示了两者在关键要素上的区别：
| 对比项 | 本地 SDK API | 远程 Web API |
|---|---|---|
| 核心载体 | 库文件、头文件、运行时组件 | HTTP 请求包 |
| 典型示例 | Steamworks SDK 接口 | Steamworks Web API、RAWG API |
| 执行位置 | 游戏进程内部 | 外部服务器 |
| 依赖条件 | 需集成到构建环境 | 需网络连接与鉴权 |
| 主要优势 | 低延迟、离线可用 | 灵活更新、数据聚合 |
这种分层方式比强行套用“渲染”或“引擎”标签更符合现状。目前没有通用文档将 DirectX 或 Unity 列为行业标准分类，也没有证据表明技术体系本身定义了接口边界 [5]。真正的界限在于：你的代码是跑在本地机器上，还是通过网络去够远处的服务。
第二层标准：按功能对象归纳用户、网络与内容服务
第二层分类标准按功能对象归纳，将所有接口最终指向解决用户身份验证、网络连接、游戏内容获取及平台发行服务等四类具体问题。
Steamworks 文档里列着一长串接口，RAWG 的后台则堆满了游戏元数据。它们看起来杂乱无章，但细看会发现，所有接口最终都在解决四类具体问题：你是谁、怎么连网、有什么内容、以及怎么发行。这种分类不是官方发布的行业铁律，而是基于现有文档索引的操作归纳。[3][4]
从文档索引看功能对象的分布
不同平台的接口文档直接暴露了其核心服务对象。Steamworks 的本地 SDK 索引中，ISteamUser 负责身份验证，ISteamHTTP 处理 HTTP 请求，ISteamNetworking 管理底层套接字连接。这些接口直指“人”的身份确认与“网”的通信通道。[3]
相比之下，RAWG 的 Web API 索引则完全围绕数据对象展开。它的端点设计用于获取游戏元数据、平台信息、用户评分、预告片视频以及 DLC 和系列关联数据。[4] 这里没有底层的网络握手或用户登录逻辑，只有纯粹的内容查询与聚合。
为了看清这两类功能的差异，我们可以对比它们在文档中的具体落脚点：
| 对比维度 | Steamworks (本地/混合) | RAWG (远程 Web) |
|---|---|---|
| 核心对象 | 用户身份、网络连接 | 游戏元数据、评分、媒体 |
| 典型接口 | ISteamUser, ISteamHTTP |
/api/games, /api/ratings |
| 交互性质 | 实时状态维持、协议握手 | 静态数据拉取、资源检索 |
| 依赖环境 | 需嵌入运行时组件 | 仅需 HTTP 请求能力 |
| 服务目标 | 保障运行与社交关系 | 构建内容与社区生态 |
这种差异并非偶然。当你调用 Steamworks 的登录接口时，你在处理“人”；当你抓取 RAWG 的游戏封面时，你在处理“物”。[2] 同一接入形态（如 Web）可能同时承载用户服务与内容查询，而同一功能对象（如网络通信）也可能通过本地库或远程请求实现。因此，将接口简单切割为互斥的功能清单会丢失关键信息。
目前的证据表明，这种按“功能对象”划分的方法，只是对现有接口条目的有效整理。它帮助我们理解不同文档背后的业务逻辑，而非定义某种不可更改的行业标准。真正的分类逻辑，依然要回到第一层的接入形态上去寻找答案。
结论：理解游戏 API 的本质是“接入关系”而非“功能清单”
理解游戏 API 本质应聚焦于接入关系而非功能清单，需先区分本地 SDK 与远程 Web API 的接入形态，再界定其服务的用户、网络或内容对象。
把游戏接口拆成“渲染、引擎、网络”往往走不通，因为现有文档没给这些类别提供统一标准 [1][2]。更稳妥的做法是看它怎么连上服务：先分接入形态，再定功能对象。第一层区分本地 SDK 与远程 Web API，前者嵌入构建环境，后者靠网络请求调用 [3][4]。第二层归纳用户身份、网络通信或内容数据等具体对象 [3][4]。
这种双层结构不是行业强制标准，而是基于 Steamworks 和 RAWG 等文档的分析工具。同一功能可能同时出现在本地库和远程接口里，比如用户登录既能在 SDK 里完成，也能通过 Web 请求实现 [2][3]。因此，“本地/远程”与“用户/内容”是交叉维度，不应被压缩成互斥的盒子。
开发者在实际应用中应灵活组合这两个维度。别把分类当教条，要把它当作拆解复杂系统的操作指南。认清接口本质是规定“如何进入”，而不是罗列“有什么功能”，才能避免在技术选型时陷入僵化框架。
FAQ：关于游戏接口分类的常见疑问
Q: 既然没有“渲染 API”这个分类，那 Direct3D 算什么？ A: Direct3D 属于图形编程库或驱动程序接口，它确实存在，但在讨论“游戏服务接口”（如登录、存档、排行榜）时，我们通常关注的是业务逻辑层面的连接方式，即它是通过本地库还是网络请求来实现的，而不是底层的图形管线。
Q: 我的游戏既有本地功能又有云端功能，该怎么选？ A: 这恰恰印证了“双层分类法”的价值。你可以使用本地 SDK 处理高频、低延迟的交互（如本地存档），同时利用远程 Web API 处理数据同步和跨平台数据聚合。两者并不冲突，关键在于根据场景选择最合适的接入形态。
Q: 为什么有些文档看起来是按功能分类的？ A: 很多官方文档为了方便开发者查找，会按功能模块（如“用户系统”、“匹配系统”）组织。但这只是文档的编排逻辑，并非技术实现的根本分类。深入源码你会发现，同一个“用户系统”模块下，可能同时包含了本地 SDK 调用的代码片段和远程 HTTP 请求的逻辑。
参考来源
- Steamworks API 概览 （Steamworks 文献库） · https://partner.steamgames.com/doc/sdk/api?l=schinese（A级）
- Web API 概览 （Steamworks 文献库） · https://partner.steamgames.com/doc/webapi_overview?l=schinese（A级）
- Steamworks API 索引 （Steamworks 文献库） · https://partner.steamgames.com/doc/api?l=schinese（A级）
- Explore RAWG Video Games Database API • RAWG · https://rawg.io/apidocs（B级）
- Gaming APIs · https://www.freepublicapis.com/tags/gaming（C级）