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 설계상의 특이점인가요?
더욱 이상한 점은, external_id로 사용자를 조회할 때 /users/by-external/:id.json을 호출하면 single_sign_on_record가 반환되지 않는다는 것입니다.
결국 이 API에는 몇 가지 특이점이 있네요… 어떤 경우에는 사용자 객체에 single_sign_on_record 속성이 있고, 어떤 경우에는 없습니다 
설계상 관리자 엔드포인트는 비관리자 엔드포인트보다 더 많은 데이터를 반환합니다. 둘 다 “user” 레코드를 가져오지만, 일반 사용자가 호출할 수 있는 /user/... 엔드포인트가 /admin/user/...와 동일한 내용을 반환한다면 매우 위험할 것입니다.
아하, /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/를 호출하면 그렇지 않아요.
이 모든 것이 큰 문제는 아니에요. 진행하면서 하나씩 파악해 나가고 있으니… 더 진도가 나가면 문서를 조금 다듬어 이 부분을 더 명확히 할 수 있는지 한번 살펴볼 생각입니다.
여기서 구분이 되는 이유는 엔드포인트가 UI에서 페이지를 렌더링하는 데 필요한 데이터를 반환하기 때문입니다. 아래를 참고하세요:
네, 완전히 이해합니다. 그리고 저는 그 트릭을 사용해 모든 XHR 요청을 모니터링하고 있어요. 다 괜찮은데요. 다만… 일관성이 좀 부족하네요. 그래도 Discourse가 이렇게 강력한 API를 제공해줘서 정말 감사드립니다!