基于Microsoft Graph的场所/会议室坐标相关API及扩展技术咨询

1. 是否存在可获取带物理地址或坐标的场所/会议室节点的API？ #

目前在Microsoft Graph的beta版本中，其实有beta/places API可以获取会议室场所信息，其中的room类型对象自带physicalAddress属性（支持存储街道、城市、邮编等结构化地址信息），不过默认确实没有直接的经纬度坐标字段。

而v1.0版本里暂时没有专门的场所/会议室节点来承载这类地址数据，你提到的beta/me/findRooms API确实只返回邮箱、会议室名称、容量等基础信息，无法获取地址或坐标。

2. 若不存在该API，选择哪个对象进行架构扩展以添加坐标信息最优？ #

如果要补充坐标信息，优先选择beta版本中的room资源（属于places集合）进行架构扩展（schema extension），这是最合理的方案：

• 语义匹配：room资源本身就是为会议室/物理场所设计的，和你的业务场景完全契合，不会出现数据关联错位的问题。
• 查询支持：架构扩展支持通过Graph API进行过滤、排序等操作，后续你可以直接查询带坐标的会议室，比开放扩展（open extensions）更实用。
• 可维护性：扩展和资源本身绑定，后续维护或迭代时，数据结构更清晰。

你可以定义一个包含latitude（纬度）和longitude（经度）字段的架构扩展，将其附加到room对象上，就能完美把坐标和会议室关联起来。

3. 是否可自定义节点（如Site）并建立与/user的PRESENT_AT关联关系？ #

首先要明确：Microsoft Graph目前不支持自定义全新的资源节点——你提到的Site其实是Graph中已有的SharePoint站点资源，并非可以自定义的通用场所节点。

要实现User-[PRESENT_AT]->Room的关联结构，有两种可行的替代方案：

• 方案一：扩展User资源存储关联：在user资源上添加架构扩展或开放扩展，存储当前用户所在room的ID。查询时，先获取用户的扩展字段，再关联到对应的room对象（已包含坐标），就能实现用户和位置的绑定。
• 方案二：利用现有关系扩展：如果你的会议室属于Azure AD中的对象，也可以通过自定义安全属性来标记用户与会议室的关联，但这种方式不如直接存储room ID直观。

另外，Microsoft Graph目前不支持自定义资源之间的关联关系（比如你说的PRESENT_AT），只能通过上述扩展方式间接实现关联。

内容的提问来源于stack exchange，提问作者Sebastian Zolg