3. Teamcenter REST接口概览与认证机制

Teamcenter 从 TC 11 起逐步提供基于 HTTP 的 REST 接口，到 TC 13/14 已形成较完整的 REST 服务面。与早期 SOA（Service Oriented Architecture）通过 SOAP/HTTP 暴露服务不同，REST 接口以资源为中心，用 URL 定位对象、用 HTTP 方法表达动作、用 JSON 承载数据。理解端点结构、资源命名、方法语义以及认证链路，是后续所有 REST 开发工作的前提。

3.1 REST 端点结构与资源命名规范

Teamcenter REST 的基础路径通常形如 https://<tc_host>:<port>/tc/，其后跟随服务族、版本、资源类型与资源标识。一个典型的端点可以拆解为：

https://tc.example.com:8443/tc/
  └─ /core-2011-06
       └─ /objects
            └─ /{uid}
                 └─ /properties

其中 core-2011-06 是服务族与版本标识，Teamcenter 用这种“服务名-版本”的方式保证接口向后兼容；objects 是资源集合；{uid} 是 Teamcenter 内部对象的唯一标识（UID），通常形如 AAAAA1B2C3D4E5F6；properties 是子资源。资源命名遵循以下约定：

• 集合资源用复数名词，如 objects、items、datasets、workspaces；
• 单个资源用 UID 或业务键作为路径参数，如 /objects/{uid}；
• 子资源挂在父资源之后，如 /objects/{uid}/properties、/objects/{uid}/relations；
• 动作型操作使用子路径而非动词，如 /objects/{uid}/revise、/objects/{uid}/checkout；
• 查询参数用于过滤、分页与投影，如 ?fields=object_string,owning_user&pageSize=50。

需要特别注意的是，Teamcenter 的 UID 是会话无关的持久标识，而 object_string 只是显示名，不能作为稳定键使用。在跨系统集成时，应始终以 UID 作为主键。

3.2 HTTP 方法语义

REST 接口对 HTTP 方法的语义有明确约定，Teamcenter 的实现基本遵循这一约定：

实际开发中常见的误区是把所有操作都写成 POST。例如“修改对象属性”应使用 PATCH 或 PUT，而不是 POST 到某个自定义动作端点。方法选择错误会导致接口语义混乱，也会影响缓存、重试与幂等性设计。

3.3 认证机制：OAuth2、SSO 与 Ticket

Teamcenter REST 支持多种认证方式，选择哪种取决于部署形态与调用方类型。三种主流方式的关系可以用下面的信号链来理解：

OAuth2 是当前推荐的认证方式。客户端先向 IdP 请求授权，获得 access_token 后，在每次 REST 请求的 Authorization 头中携带 Bearer <token>。Teamcenter 服务端会校验 token 的签名、有效期与作用域，并映射到对应的 Teamcenter 用户会话。SSO 通常与 OAuth2 结合使用，由企业 IdP（如 Azure AD、Keycloak）完成用户身份验证，Teamcenter 作为资源服务器信任 IdP 签发的 token。

Ticket 认证则更适用于服务端到服务端的受信调用。调用方先通过 SOA 的 getServiceTicket 或 REST 的认证端点获取 Ticket，再在请求头中携带。Ticket 的有效期通常较短，且与获取它的会话绑定，适合在批处理、后台任务中使用。

3.4 Token 管理与刷新策略

Token 管理是 REST 集成中容易被忽视但影响稳定性的环节。access_token 通常有效期在 30 分钟到 1 小时之间，refresh_token 有效期更长。合理的做法是：

• 在内存中缓存 access_token 及其过期时间，避免每次请求都重新获取；
• 在 token 过期前 5 分钟主动刷新，而不是等到 401 再重试；
• refresh_token 失效时回退到完整的授权流程；
• 多线程环境下对 token 刷新加锁，避免并发刷新导致旧 token 被覆盖。