【AICon】探索RAG 技术在实际应用中遇到的挑战及应对策略!AICon精华内容已上线73%>>> 了解详情
写点什么

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

评论

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

M-DAO开辟区块链全新战场,或成DAO赛道龙头

西柚子

在线文本代码对比工具

入门小站

工具

Notification发送消息

空城机

WebApi 5月月更

一站式Dao打造工具M-DAO:门槛低、效率高

股市老人

拆分电商系统为微服务

小虾米

「架构实战营」

在线HTML转Excel工具

入门小站

工具

Kubernetes 安全权限管理深度剖析

liuzhen007

k8s 5月月更

linux之sed使用技巧

入门小站

Linux

[Day45]-[BFS]-滑动谜题

方勇(gopher)

LeetCode BFS 数据结构算法

字节跳动 CloudWeGo 官方微信公众号官宣了!

baiyutang

Go 开源 微服务 5月月更

ES6 之set详解

达摩

js

[Day44]-[回溯]-括号生成

方勇(gopher)

LeetCode 回溯算法 数据结构算法

干货| 四种渲染到底是啥?终于有人讲明白了!(下)

Orillusion

开源 WebGL 元宇宙 Metaverse webgpu

druid 源码阅读 9—— init 中的JMX是干啥的

张大彪

设计模式之责任链模式

乌龟哥哥

5月月更

Druid连接池源码阅读09

石小天

千亿级高并发MongoDB集群在某头部金融系统中的应用及性能优化实践(上)

杨亚洲(专注MongoDB及高性能中间件)

数据库 mongodb 分布式 高性能 分布式数据库mongodb

代码之外:写作是倒逼成长的最佳方式

宇宙之一粟

写作 5月月更

css 学习笔记【三】浮动,不脱离文档流,继承和层叠

恒山其若陋兮

5月月更

使用 Provider 改造屎山代码,代码量降低了2/3!

岛上码农

flutter ios 安卓开发 跨平台开发 5月月更

druid源码阅读(十)Druid keepAlive参数

爱晒太阳的大白

5月月更

零基础学Java第三节(基本输入输出)

编程攻略

java开发学习

JS Iterable object (可迭代对象)

达摩

js

M-DAO开辟区块链全新战场,或成DAO赛道龙头

小哈区块

六、云原生可观测性

穿过生命散发芬芳

可观测性 5月月更

M-DAO开辟区块链全新战场,或成DAO赛道龙头

BlockChain先知

Redis「8」实现分布式限流与延时队列

Samson

redis 学习笔记 5月月更

抖音打击炫富违规视频:自媒体行业的底线在哪

石头IT视角

数据库连接池 -Druid 源码学习(九)

wjchenge

Druid 数据库连接池

初始C语言

芒果酱

C语言 5月月更

Linux环境编译单个C程序文件

Loken

音视频 5月月更

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