当我使用 API 获取 Discourse 用户对象时，一切正常，但我没有在其中看到 external_id。如果我有 Discourse 用户 ID 或用户名，该如何从中获取 external_id？
啊哈——我调用的是 /users/blake.erickson.json（没有 /admin），它也会返回一个用户对象，但不包含 single_sign_on_record。
嘿，为什么 /users/ 端点只接受用户名，而如果想通过 Discourse ID 获取用户，却要用 /admin/users/:id.json？这只是 API 设计的 quirks 吗？
更奇怪的是：如果我通过 external_id 获取用户，调用 /users/by-external/:id.json，同样得不到 single_sign_on_record。
所以这个 API 确实有些 quirks……有时候用户对象包含 single_sign_on_record 属性，有时候又没有 
根据设计，管理员端点将返回比非管理员端点更多的数据。是的，它们都在获取“用户”记录，但如果普通用户可以调用的 /user/... 端点返回与 /admin/user/... 端点相同的内容，那将是非常糟糕的。
啊，我没想到 /user 端点会对普通用户开放。我忘了还有用户 API 密钥这回事。
我总被各种不一致的地方搞得晕头转向。目前，如果我想获取 single_sign_on_record，就必须知道 Discourse 用户 ID（/admin/users/:username.json 不起作用）……但大多数其他 API 调用似乎都需要用户名（例如 /users/:username.json）。
此外，还有一些非常相似、看起来几乎完全一样的独立 API 端点，却返回不同的结果。比如 /admin/users 会返回用户的 single_sign_on_record 数据，但直接调用 /users/ 则不会。
这些都不是什么大问题，我正在边做边摸索……等再深入一些后，我可能会尝试调整一下文档，让其中一些内容更清晰易懂。
这里的区别源于这些端点返回的是在用户界面中渲染页面所需的数据。请查看此处：
当然，我完全理解——我一直用那个技巧来监控所有的 XHR 请求。一切都没问题，只是……有点不稳定。 不过，我非常感激 Discourse 拥有如此强大的 API！