写点什么

在 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:133925

评论

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

leetcode 72. Edit Distance 编辑距离(中等)

okokabcd

LeetCode 动态规划 算法与数据结构

蓝队攻防演练中的三段作战

穿过生命散发芬芳

攻防演练 7月月更

认识ThreadPoolExecutor

zarmnosaj

7月月更

后CentOS时代的操作系统漫谈

冯骐

centos 开源 openEuler 国产化 Anolis

如何用一个插件解决 Serverless 灰度发布难题?

阿里巴巴云原生

阿里云 Serverless 云原生 插件 灰度发布

繁华落尽、物是人非:个人站长该何去何从

石头IT视角

图解网络:什么是网关负载均衡协议GLBP?

wljslmz

网络协议 7月月更 GLBP 图解网络 网关负载均衡协议

跨域请求

Jason199

跨域 7月月更

C语言中sizeof操作符的坑

Albert Edison

c++ C语言 7月月更 sizeof

官宣!第三届云原生编程挑战赛正式启动!

阿里巴巴云原生

阿里云 Serverless 边缘计算 ACK 云原生编程挑战赛

Vuex(三)

小恺

7月日更

Qemu Linux

贾献华

7月日更 7月月更

关于栈区、堆区、全局区、文字常量区、程序代码区

NewBoy

前端 移动端 iOS 知识体系 7月月更

浅聊一下中间件

为自己带盐

中间件 7月月更 dotnetcore

HPDC智能基座人才发展峰会随笔

乌龟哥哥

7月月更

牛客java选择题每日打卡Day6

京与旧铺

7月月更

质量体系建设之路的分分合合

声网

创业讲堂 生态专栏

可观测|时序数据降采样在Prometheus实践复盘

阿里巴巴云原生

阿里云 云原生 Prometheus 可观测

算法入门很简单:链表题套路及精选题目

宇宙之一粟

链表 7月月更

什么是数据治理?为何华为愿意200万年薪聘数据治理专家?

雨果

数据治理 DaaS数据即服务

TLA+ 入门教程(1):形式化方法简介

多颗糖

分布式系统 TLA+

Java实现单例模式

lambochen

单例模式

LLVM之父Chris Lattner:为什么我们要重建AI基础设施软件

OneFlow

人工智能 软件系统

OpenFeign

急需上岸的小谢

7月月更

2022-Java后端工程师面试指南-(Java基础篇)

自然

Java’ 7月月更

OpenHarmony资源管理详解

坚果

HarmonyOS OpenHarmony 6月月更

线上故障突突突?如何紧急诊断、排查与恢复

阿里巴巴云原生

阿里云 微服务 云原生 故障恢复 诊断

ORACLE进阶(三)数据字典详解

No Silver Bullet

oracle 7月月更 数据字典

【愚公系列】2022年7月 Go教学课程 003-IDE的安装和基本使用

愚公搬代码

7月月更

【Docker 那些事儿】容器为什么傲娇?全靠Hub撑腰

Albert Edison

7月月更

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