3.1.3 DELETE 请求

DELETE 请求专用于删除服务器端的资源对象。在 Ambari 的请求处理体系中，DeleteHandler 负责接收和解析所有 DELETE 请求，最终通过 AbstractAuthorizedResourceProvider 的 deleteResources() 方法实际执行资源的删除操作。

• 流程分解：

  • 请求抵达后由 DeleteHandler 统一调度，先检查请求合法性（如参数、URI 有效性）。
  • 随后调用 deleteResources() 执行实际删除。该方法默认集成权限验证逻辑，保障只有具备相应权限的用户才能进行删除。

• 权限校验机制：

  • deleteResources() 内部会先调用 deleteResourcesAuthorized()，根据当前用户权限判断能否进行资源删除，符合 RBAC 安全最佳实践。
  • 可扩展性：如果 Provider 子类重写了 deleteResources() 并省略了权限验证，则可实现特殊场景下的权限绕过（需谨慎）。

• 典型应用场景：如批量节点下线、组件卸载、服务清理等都依赖 DELETE 请求链路。

3.1.4 PUT 请求

PUT 请求主要用于更新或替换现有的资源对象。Ambari 使用 UpdateHandler 作为 PUT 请求的核心处理器，并通过 AbstractAuthorizedResourceProvider 的 updateResources() 完成资源的持久化变更。

• 流程分解：

  • UpdateHandler 首先接收并校验 PUT 请求的内容结构（通常为完整资源对象或需更新的字段集合）。
  • 调用 updateResources()，按业务规则更新数据库或内部状态。

• 权限校验机制：

  • updateResources() 默认内嵌 updateResourcesAuthorized() 权限检查，严格防止未授权修改。
  • Provider 子类若重写 updateResources() 而未显式调用授权方法，则有可能跳过权限校验，务必配合审计和安全自查。

• 典型应用场景：如服务参数调整、节点标签变更、状态切换等配置管理动作。

3.2 Request 和 Handler 的协作关系

在 Ambari 架构中，Request 封装了前端传来的所有请求数据，Handler 负责将其映射为实际的业务操作。每个 HTTP 请求方法都严格对应着专用 Handler 实现，保证流程规范与行为解耦。

HTTP 请求方法	对应 Handler	资源操作方法	默认授权检查
GET	ReadHandler	getResources()	getResourcesAuthorized()
POST	QueryPostRequest / PostRequest	createResources()	createResourcesAuthorized()
DELETE	DeleteHandler	deleteResources()	deleteResourcesAuthorized()
PUT	UpdateHandler	updateResources()	updateResourcesAuthorized()

• 每个 Handler 专注于一种资源操作，代码更清晰，逻辑更专一。
• 默认情况下所有敏感操作都需经过授权方法，但Provider 层的重写为特殊业务逻辑预留了灵活扩展口。

3.3 Provider 层重写方法与权限安全

AbstractAuthorizedResourceProvider 提供了全套的默认资源操作（增删改查）与权限校验挂钩方法。 Provider 层的自定义重写行为将直接影响权限链路！

• 不重写时：权限链路完整，安全性高，调用顺序标准。
• 重写后：如在 Provider 重写 getResources()、deleteResources() 等方法时，如果没有调用父类的 xxxResourcesAuthorized() 方法，则会绕过默认权限校验，存在安全风险。

示例代码：

@Override
public Set<Resource> getResources(Request request, Predicate predicate) throws SystemException, AuthorizationException {
    // 自定义逻辑，未显式调用 getResourcesAuthorized()，默认授权逻辑失效
    return super.getResources(request, predicate);
}

警告

注意：自定义 Provider 时，必须明确是否需要跳过权限检查，任何省略都要留有安全和业务审核记录！

4. 最佳实践与实战技巧 💡

4.1 明确请求-Handler 映射关系

• 每个 HTTP 请求类型（GET/POST/PUT/DELETE）对应唯一 Handler，Handler 再决定具体调用哪个 Provider 方法。
• Request 和 Handler 分离让代码维护更简单，流程也更易测试和扩展。

4.2 严格把控权限链路

• 强制显式授权：在所有自定义 Provider 资源操作中，务必在关键位置调用 xxxResourcesAuthorized() 方法，保障权限链路完整。
• 日志与审计：对高危操作（如 DELETE、PUT），建议增加日志与安全审计，实时捕捉潜在越权行为。

4.3 灵活扩展但不滥用重写

• Provider 方法重写强大但有风险。只在有特殊业务需求且经风险评估后才重写，且注明为何绕过权限控制。
• 对于通用资源和常规请求，尽量复用 AbstractAuthorizedResourceProvider 默认实现，降低维护和安全负担。

4.4 结合 applyDirectives 实现复杂业务流转

• 利用 applyDirectives 机制，可以灵活实现“查询+批量创建”、“条件更新”、“安全分支”等高阶业务流转。
• 新的请求类型或业务扩展时，也能通过工厂与 Handler 解耦平滑接入。

5. 总结与延伸学习 🚀

5.1 主要收获

• 请求与 Handler/Provider 的映射和职责划分让 Ambari REST API 架构兼具灵活与规范。
• 权限控制机制依赖 Provider 方法的实现细节，安全性与灵活性需权衡把控。
• Request 工厂与 applyDirectives 为各类请求和业务场景提供了统一且可扩展的分发与控制入口。

5.2 推荐下一步学习

• 研读 Provider 层核心源码，深刻理解权限验证、资源操作与自定义逻辑的协作模式。
• 分析实际场景下的 Handler/Provider 重写案例，学会安全高效地扩展 REST API。
• 探索 applyDirectives、QueryPostRequest 等机制在大规模自动化场景下的实战用法。