从前合作开发或预览 API 时，他们时常须要深入细致探讨对 API 的内部结构、重新命名和机能等，这个耗费了大批的时间。
随着 API 行业的飞速产业发展，API 内部结构设计也愈来愈关键。这么十多年产业发展留下来，一些如 REST API 等等的准则也受绝大多数人普遍认可，这些准则能应用领域于合作开发业务流程中，协助项目组加速达成一致一致意见，达到增效的目地。
接下去会如是说 API 内部结构设计的基本原理和准则。而在责任编辑中，他们将著眼于 Web API。
Mauvezin一句话来解释一下，API 是 Application（插件）、Programming（程式设计）和 Interface（USB）的简写女团，简而言之，透过一个撰写好的USB，相连两个插件，能外部选用，也能对外开放。
大体上，每天他们选用 Web 插件、推送最新消息或出访某一 URL 时，都在选用相关联的 API ，不论它是应用领域程序插件还是服务器插件，都是透过 API 来传递统计数据。
由于 API 和其他所有人之间的大部份通讯都是透过 HTTP 顺利完成的，因此 HTTP 十分关键，须要根据相同的目地和市场需求，选用相同的允诺方式：
GET — 允诺选定天然资源的则表示。选用 GET 的允诺应该只索引统计数据。
POST — 向指定天然资源递交统计数据。
PUT — 用允诺统计数据代替最终目标天然资源的大部份现阶段则表示。
DELETE — 删掉选定的天然资源。
PATCH — 对天然资源应用领域部分修正。
合作开发设计在急速产业发展，API 构架和协定也愈来愈多。相同的构架和协议，在制订统计正则表达式、指示方式、机能上都有所相同。从前最盛行的是如前所述 XML 的协定，现在也渐渐被 JSON 替代。
而当今世界上最常见的 API 构架毫无疑问是 REST 。当他们选用 REST API 时，必须遵循 JSON 的规范，以有效的 JSON 格式发出测试允诺。好的 API 通常会遵循这些准则：
API 必须与后端、统计数据存储、应用领域程序等分开。考虑到安全性和灵活性，API 必须是单独的层级；
不同的允诺应该互不干扰，独立处理。这也意味着每个允诺都须要包含处理它所需的大部份信息；
API 应该独立于应用领域程序外推送允诺，以相同的方式工作。例如在 Web 服务器、负载平衡器还是任何其他应用领域程序；
REST API 的响应也能包含可执行代码（如 Java 小程序）。这些情况下，代码能只按需运行；
天然资源应该在应用领域程序或服务器端应该是可缓存的。这能提高应用领域程序的性能，同时提高服务器端的可拓展性；
处理错误并返回相应的错误代码。协助用户了解是404还是其他问题；
API 必须是有容错的。用户有时因为物理原因如网络超时等，发出了重复的允诺，这样的允诺应该返回相同的结果；
选用 Eoapi 或其他工具生成规范的 API 文档。不管是选用还是工作交接，都须要用到 API 文档。
重新命名端点也有一些很好的方式：
只选用名词：端点应该用选定天然资源内容的名词重新命名，而不是为正在执行的机能添加动词。例如重新命名端点 /users 并选用相同的 HTTP 方式来处理用户实体，而不是创建多个 /get-user 、/add-user 等端点；
选用清晰的名称：端点的名称应该清晰直观。不要选用任何快捷方式或简写，除非很明显 – /ids 是能理解的并且比 /identification-numbers 更可取；
透过正斜杠构建层次内部结构：将端点分组为逻辑组。如 /departments/ids 和 /departments/managers ，比 /departments-ids 和 /departments-managers 更好；
仅选用小写：URL 是区分大小写的，因此最好尽量避免选用大写；
选用“-”分隔单词：端点名称中的相同单词通常用“-”分隔，而不是下划线或骆驼拼写法；
避免选用特殊字符：URL 只能选用 ASCII 字符集推送和接收，因此能只选用该字符集中的字符。同时其他如“%”，“[]”，“{} ”,“|”,“,”“<>” 最好也尽量避免选用。
绝大多数 REST API 是与微服务构架一起制作的。在这种情况下，这种 API 内部结构将提供更改底层逻辑、添加或删掉组件等的灵活性，而无需更改与其他服务的其他通讯协定。
相信你也对 Web API 的内部结构设计有了一定的了解了，这是无数人验证过的合理的优秀的方案，尝试一下应用领域到工作中吧！
关于他们
我叫 Eoapi，我是一款类 Postman 的开源 API 工具，我更轻量，同时可拓展！我能简化你的 API 合作开发工作，让你更快更好地创建 API。
