写点什么

在 RESTful 服务中实现部分更新

  • 2010-12-06
  • 本文字数:1915 字

    阅读完需:约 6 分钟

近期 Alex Scordellis 发表了一篇文章,文章主题是如何针对客户端与 RESTFul 服务的交互进行建模和设计,实现部分资源的更新。

[在 REST In Practice (由 Ian Robinson Jim Webber Savas Parastatidis 合著)这本书中] 有个问题很让我困扰,作者们推荐使用 POST 方式更新资源的状态。这是根据对 PUT 语义的解释做出的选择。根据 HTTP 规范的描述:

如果请求的 URI 指向已经存在的资源,那么封装的实体应该被视为驻留在原始服务器上实体的修改后的版本。

在这本书里,作者们对此的解释是,在同一个 URI 里,PUT 请求封装的正文(body)中应该包含与 GET 请求的表现形式相同的元素。由于我们正在使用 HATEOAS 风格,表现形式包括链接和其他超媒体表现形式。其含义就是客户端 PUT 的内容应该同时包含业务数据(例如咖啡订单的新内容)和超媒体控件(工作流程中的下一个有效步骤)。

Alex 的观点是服务的超媒体和资源展现形式应该驱动客户端的工作流,并且他提出了四种可能的方法针对这种交互方式进行建模。其中一些例子可以从 RESTBucks 的文章里找到。

使用 PATCH […] 这种方式没有得到广泛的支持。我也觉得它语义上存在问题。从客户的角度来看,业务数据组成的订单(多少杯拿铁?)就是整个资源。客户并不会把这种方式看做是 PATCH,而会看做是替换,例如 PUT。PATCH 对于阐述像“在拿铁中放脱脂牛奶,而不是我原来定的全脂牛奶”这样的场景才有意义。 使用 POST 这种方法是书中推荐的。对我来说,它与 PATCH 有类似的问题。POST 意味着追加资源。在咖啡订单资源里 POST 一杯卡布奇诺,感觉就像追加了一杯卡布奇诺,而不是用卡布奇诺替换原有咖啡订单。 使用 PUT,包含超媒体 如果遵循严格的解释,PUT 应该包括整个展现形式,客户端同时发送完整新咖啡订单和所有的超媒体控件。
使用 PUT,不包含超媒体 客户端发送新订单的完整展现形式,但没有链接。我觉的这个概念是对的。客户端通过发送可用的部分数据的完整表现形式来满足 PUT 的需要,但并不负责哪些超媒体控件是有效的。

经过与 @serialseb @iansrobinson @jimwebber 讨论之后,Alex 总结了以下规则,这也满足了 PUT 作为动词语义的期望。

针对 GET 请求的响应,服务提供现有状态的完整表现形式,包括业务数据和有效的超媒体控件。客户端 PUT 由其负责的那部分数据的完整展现形式。

针对这一讨论,William Vambenepe补充了其他需要注意的事项

我们来举个简单的例子。如果一个元素没有在部分更新中描述,这意味着什么?是明确的删除动作,表示在展现形式中删除该元素?或表示“不要改变其当前值”。如果是后者的话,我怎么做删除操作呢?是需要部分 DELETE,就像部分 PUT 一样?我希望不是,否则必须要有一种机制来实现类似 PUT 的部分删除元素。空值?这和并不存在的元素不是一回事。Nil 值?那么我如何在 JSON 中处理它呢?

他声称,设计部分资源更新是个十分困难的问题,现在正试图通过规范解决,例如 WSDM、WS-Management 和 WS-ResourceTransfer。

好消息是我们已经犯了很多错,而且已经得到了很多经验教训(参阅 technical rant post-mortem experiment )。坏消息是有大量的新的错误还在等待着我们。

Stu Charlton 同样对这个问题抱有疑惑,而且他指出了这样一个事实,RESTFul 超媒体不能真正描述数据模型。据他而言,RESTful 服务要想具备更好的交互能力,还需要做以下两件事:

(a)[封闭的] 数据模型覆盖 80% 的公共用例,可以基于 JSON 和 XML 格式进行描述。

(b) 多媒体类型覆盖 80% 的公共用例,用来描述资源的生命周期和状态转移──换句话说,就是让 POST 在超媒体中实现自描述。因为计算机的世界不仅仅是更新数据,更多是关于抽象的描述。

针对 Alex 发表的文章的评论:

你应该具备 / 两种 / 资源:客户端的订单告诉服务器它想要什么,服务端的“票据”负责与客户端确认详细信息──增加任何其需要的附加数据、链接等。服务端的票据依赖于客户端的订单,包括在订单执行过程中任何内外部流程的状态。但谁来提供客户订单呢?当然是客户端!那么,除非你有一个不对称的设置,在这种情况下,客户端可以 POST 和 / 或 PUT 它的订单到服务器的某处。现在客户端可以一次性提交和改变 / 整个 / 订单资源,不需要担心任何服务端产生的数据。

有很多提议用来解决这一问题,而且,如果能够对资源进行恰当的建模,这个问题似乎可以很容易解决。很多时候会考虑到,把资源作为实体来支持 CRUD 操作也是同样的问题,只有把建模的资源作为“资源”和提供的服务,就像在 Duncan Craggs 示例中一样,才是解决问题的方案。不过更大的问题是如何让所有人都同意这个方案。请仔细阅读初始文章评论,并分享你的观点。

查看英文原文: Implementing Partial Updates In RESTful Services

2010-12-06 09:133945

评论

发布
暂无评论
发现更多内容

Kafka集群升级项目实施方案,打造高效数据处理平台

敏捷调度TASKCTL

kafka hadoop cloudera 集群 大数据运维

OCR+PDF解析配套前端工具开源详解!

合合技术团队

#开源 #前端 ODR

社区周刊·Vol.182

华为云开发者联盟

开发者 华为云

解锁极致性能:Arm Cortex-X925 IPC 提升15%,终端用户体验感再突破

新消费日报

实现MySQL异地多活场景

NineData

数据一致性 数据同步 异地多活 NineData 单元节点

大数据存储计算平台EasyMR:多集群统一管理助力企业高效运维

袋鼠云数栈

用豆包MarsCode 和CozeAPI接口全自动做一个文生图组件

豆包MarsCode

人工智能 大数据 AI Chat

大模型在商业领域的应用:如何提升决策效率与用户体验

测吧(北京)科技有限公司

测试

除了deadline,我们还能用什么驱动开发?

思码逸研发效能

程序员 DevOps 软件开发 编码 IT 运维

罗格科技:全球税务服务领域初露锋芒 罗格罗拉国际税大模型发布

科技热闻

揭秘京东商品详情一键获取的API之旅

代码忍者

pinduoduo API API 性能测试

国内外大模型应用的现状与未来:以ChatGPT、Mixtral和Llama为例

测吧(北京)科技有限公司

测试

AIGC技术的变革:语音识别与视觉识别的深度融合

测吧(北京)科技有限公司

测试

深度学习在视觉识别中的突破:从理论到实践

测吧(北京)科技有限公司

测试

AI时代,2024火山引擎飞连新品发布会盛大开启

新消费日报

堡垒机价格贵吗?一定要买堡垒机吗?

行云管家

网络安全 堡垒机 数据泄露

制造已然走出国门,数据如何走向全球?

奇点云

人工智能 AI 互联网 软件 制造业

SIGGRAPH Asia 2024 | 网易伏羲研究成果入选,3D面部动画技术再获新突破

网易伏羲

论文 网易伏羲

文生图与文生视频:从文本到视觉的创作革命

测吧(北京)科技有限公司

测试

开源大模型的私有部署:Llama与千问的比较研究

测吧(北京)科技有限公司

测试

智能合约与大语言模型的结合:未来的应用场景探索

测吧(北京)科技有限公司

测试

联手豆包大模型,容联七陌打造更懂客户的智能客服

新消费日报

1688电商生态新引擎:商品详情API引领行业发展新篇章

代码忍者

pinduoduo API API 性能测试

智能体Agent应用的前沿:图文、短视频与流程图的生成技术

测吧(北京)科技有限公司

测试

知识图谱融入向量数据库,带来RAG效果飞升

Zilliz

知识图谱 向量数据库 LLMs rag

同风起,耀星河!华为携手伙伴一起创造无限可能

HarmonyOS开发者

HarmonyOS

检索增强生成(RAG)技术在知识图谱中的应用:Neo4j的探索

测吧(北京)科技有限公司

测试

【论文速读】|用于安全代码评估的大语言模型:一项多语言实证研究

云起无垠

《Programming from the Ground Up》阅读笔记:p217-p238

codists

汇编 编程人

得物一面,都是非常经典的问题

王中阳Go

Go 面试 后端

在RESTful服务中实现部分更新_SOA_Dilip Krishnan_InfoQ精选文章