我不明白为什么所有 API 端点的完整文档还不存在。原始文档于 2014 年 12 月向公众发布，而六年过去了，文档仍然不完善。
这是为什么呢？缺乏良好的文档以及建议逆向工程 API，这对希望使用该 API 的开发者来说是一个重大障碍。
此致，
一位沮丧的开发者
您能否提供一些例子，说明您遇到了什么困难或觉得有哪些不足？
4 个赞
这是一个及时的话题，因为我在论坛上收到了一条警告：“我们检测到使用了已弃用的身份验证方法的 API 请求。”
我想了解当前应该使用的方法，以及从论坛管理员角度出发的实施指南。
我找到的都是过时的帖子，它们链接到了 GitHub，但作为非技术人员，代码参考对我毫无帮助。能否有人用通俗易懂的语言提供指导？
1 个赞
正确的 API 认证方法在文档的最上方有详细说明。简而言之，您需要使用 HTTP 头来提供 API 密钥和用户名，而不是通过 URL 参数。
6 个赞
@justin 我的具体例子是，我正在逐步推出一个 Discourse API 的 Python 封装库，但发现缺乏完善的文档令人难以承受。我不得不手动测试每一个接口，但其中许多接口要么没有文档，要么文档描述错误。
文档开头已明确指出 API 尚未完全文档化。我想知道：为什么？
1 个赞
查看 Reverse engineer the Discourse API
为什么海滩上的每一粒沙子都要“完全文档化”？：rofl:
4 个赞
出于好奇，为什么不先支持当前所需的功能，直到遇到新的不支持的需求时再进行逆向工程呢？这比追求100%的覆盖率要容易得多，而且封装那些永远不会被调用的函数也是徒劳的？尤其是因为你将面对的是一个不断变化的目标。让工作更轻松些吧？
2 个赞
我明白这可以被逆向工程破解。只是不得不这样做让人有点沮丧。API 是由人类创建的，他们肯定知道它是如何工作的，为什么这些人不把它写下来，以便其他人也能了解呢？
我觉得这不算过分的要求。良好的文档在任何项目中都至关重要。
1 个赞
目前的计划就是这样，我已经在我的仓库的 develop 分支中镜像了所有已文档化的端点，现在到了必须开始进行逆向工程的阶段。
我已经在为 GitHub - discourse/discourse_api_docs: Discourse API Documentation · GitHub 做贡献，但我真的很疑惑，对于一个如此成熟的项目来说，这是否真的有必要。
1 个赞
和任何事物一样，这关乎资源与优先级。API 接口面非常庞大。从技术上讲，它涵盖了一切——所有内容都通过 API 访问，这也是逆向工程能够生效的原因。我们选择将有限的工程时间投入到修复、功能开发、性能优化等方面，而不是文档编写。我们的产品方向主要由客户和社区驱动。据我所知，从未有客户要求实现 100% 的 API 文档覆盖率。当客户询问某些缺失或不清楚的内容时，我们会进行补充。因此，100% 的覆盖率一直不是我们的优先事项。
目前，API 文档是人工精心整理的。这显然不是一种可持续的方法，但现阶段我们只能如此。将 API 文档系统重构为通过程序自动生成是一个“待办”事项，但目前并未列入任何特定版本的计划中，因此尚无完成的时间表。
15 个赞