[译] 在Web API 2 中实现带JSON的Patch请求

原文链接:The Patch Verb in Web API 2 with JSON

我想在.NET4.6 Web API 2 项目中使用Patch更新一个大对象中的某个字断,这才意识到我以前都没有用过Patch。这是一次难得的学习机会。

我不知道在Web API 2中最好的实现方式是什么,所以我按照惯例,用google搜索"Patch Web API"。我得到的第一条结果是Michael McKenna’s “How to Add JSON Patch Support to Web API”。看起来只要照做就行了,但是我想知道为什么他一定要为此写个解决方案。毫无疑问地,在Web API中Patch是一个非常常见的需求,难道.NET就没有一个原生的方式实现它吗?也许Michael也不知道。

经过一番探索之后,在几乎所有的论坛和博客中都无外乎如下三种方法,却没有一个是我喜欢的。

1. 为每个属性写一个api

有人建议为每个修改写个方法,例如设置“Book.Name”,设置“Book.PageCount”等等。毫无疑问地,这种方式实现起来非常花时间,并且也不好维护,特别是当对象中有很多属性或者有很多对象的时候,简直就是天坑:(。

2. 使用ODATA

很多人建议在项目中包含.NET ODATA类库,只用它的Delta类来实现Patch请求。这看起来有点怪怪的。ODATA和简洁的JSON API比起来是一个完全不同的大家伙。我赶脚ODATA有点笨重,不直观,不优雅。

另外,好像在JSON Web API项目中用ODATA类库更新某些基础类型还有一些问题。 由于ODATA类库是为ODATA格式的数据设计的,这种格式完全不像JSON格式那么优雅。好像还有很多人使用(或者正在尝试使用)ODATA去实现JSON格式的Patch请求,但是好像都不怎么理想。

3. 使用带有可空(nullable)属性的patch类型

假设我们想实现在Book对象中更新PageCount属性。在Book类型中,Name是必须的属性,其它的像Language是可空的。这个解决方法是要创建一个Book的补丁类型,其中PageCount、Name等属性都设置成可空的。如果HTTP请求提供了某个属性的值,那么是给这个属性赋值。如果没有提供值的话,就是不改变这个属性。如果你想清空这个属性的值,那么在请求中提供null。

这好像不是那么糟糕:(,但是当传递过来的数据中的可空的属性为null时就需要在补丁类型中写额外的逻辑。还要为每个需要patch的类型写对应的补丁类型。尽管多次创建和修改早已创建好的类型还不是最坑爹的,但是维护将会是个天坑。

这个方法仅用来设置一个属性还好,如果属性是一个数组,我想在其中增加一个item,那就没办法了,除非把整个数组彻底重写来支持Patch操作。或者再为每个需要操作数组的地方写一个API。难道就没有一个优雅的方法吗?

什么是JSON Patch

经常被提起的ODATA其实并不适合,那我干嘛要非得用ODATA去实现JSON类型的Patch操作呢。最优雅的实现方式是什么?难道就没有JSON Patch标准吗?

铛铛铛!这是JSON Patch的标准: standard RFC6902。用类似于这样的指令"set field x to this value"来解释Patch操作,如此,用一个或者多个指令就能解释说明如何操作对象。它还支持其它多种操作,比如,增加、删除某个需要修补的对象中的数组元素,还有设置嵌套对象的属性等等。‘Replace‘,‘move‘, ‘copy‘ 和 ‘test‘操作都已经被定义好了。有趣的是,‘test‘方法可以检查某个属性是否和目标值相等,应该很有用。

JSON Patch看起来像下面这样:

{"foo":"bar"}

如果我们想增加一个名为"name",值为"Carly"的属性,那么发送的HTTP Patch 请求体如下所示:

[
    {"op":"add","path":"/name","vale":"Carly"}
]

我们可能得到的响应如下:

{
    "foo":"bar",
    "name":"Carly"
}

JSON Patch有自己的MIME类型: application/json-patch+json 。

它差不多解决了其它方法中的所有缺陷,并且更加RESTful :o。URI也可以和对象保持一致,只是请求中需要包含操作数据的指令,但是指令一看就懂,非常清晰。我们可以清晰地使用各种方式去操作属性,它可以将多种操作放在一次请求中。完美!

现在很多人还在提倡2003年以前JSON Patch被提出来之前的方法,其中还有一些错误的言论误导了很多的学习者。非常感谢William Durant,及其一针见血的博文“Please. Don’t Patch Like An Idiot”,是这篇博文给了我启发。我知道它虽然没有促使JSON Patch或者XML Patch被.NET原生支持,甚至都没有在.NET Web API的指南中被提及。但这种方法无疑是一个正确的且优秀的方式。

在.NET Web API 2中如何使用Json Patch

现在我们知道了正确的实现方法,那么代码怎么写呢?参考Michael’s post about JSON API的第一行引用的JSON标准。虽然Michael的博文的主要目的是介绍他的JSON Patch类库!但依然值得学习。
以下是摘来的精华:
1. Nuget 安装: Install-Package JsonPatch -Version 1.0.0
1. 支持MIME类型和格式
public static void CongigureApis(HttpConfiguration config){ config.Formatters.Add(new JsonPatchFormatter()); }
1. 在你的API Controller中实现Patch方法

public void Patch(Guid id, JsonPatchDocument<SomeDto> patchData)
{
//Remember to do some validation, error handling, and all that fun stuff
var objectToUpdate = repository.GetById(id);
patchData.ApplyUpdatesTo(objectToUpdate);
repository.Save(objectToUpdate);
}
执行patch请求的Http请求报文如下所示
PATCH /my/data HTTP/1.1
Host: example.org
Content-Type: application/json-patch+json

[
    { "op": "add", "path": "/a/b/c", "value": "foo" }
]

发展趋势

值得注意的是Json Patch类库有一点已知的issues和局限。如果你在项目中用到了它,如果你修复了它的issues或者增加了功能,还请您贡献下您的代码。

Using Michael’s JSONPatch library, there are a few scenarios that might come up. One is preventing patch of specific properties, which should be fairly easy to solve with a custom attribute added to the data model.
(这段话还没看明白)

最近,ASP.NET5好像要支持JSON Patch了.

时间: 2024-10-25 19:33:17

[译] 在Web API 2 中实现带JSON的Patch请求的相关文章

Web API项目中使用Area对业务进行分类管理

在之前开发的很多Web API项目中,为了方便以及快速开发,往往把整个Web API的控制器放在基目录的Controllers目录中,但随着业务越来越复杂,这样Controllers目录中的文件就增加很快,难以管理,而且如果有不同业务模块有重复的控制器名的话,还需要尽量避免.引入Area的作用就是把控制器按照不同的业务模块进行区分,方便管理,而且控制器名称可以重名. 1.Web API项目引入Area进行分类 Area在项目中可以称之为区域,每个Area代表应用程序的不同功能模块,Area 使每

【Web API系列教程】1.2 — Web API 2中的Action Results

前言 本节的主题是ASP.NET Web API如何将控制器动作的返回值转换成HTTP的响应消息. Web API控制器动作可以返回下列的任何值: 1, void 2, HttpResponseMessage 3, IHttpActionResult 4, Some other type 取决于返回的以上哪一种,Web API使用不同的机制来创建HTTP响应. Return type How Web API creates the response void Return empty 204 (

Entity Framework 6 Recipes 2nd Edition(9-1)译-&gt;用Web Api更新单独分离的实体

第九章 在N层结构的应用程序中使用EF 不是所有的应用都能完全地写入到一个单个的过程中(就是驻留在一个单一的物理层中),实际上,在当今不断发展的网络世界,大量的应用程序的结构包含经典的表现层,应用程,和数据层,并且它们可能分布在多台计算机上,被分布到一台单独的计算机上的应用程序的某个领域的逻辑层,并不过多地涉及代理服务器编码,序列化,和网络协议,应用程序可以跨越很多设备,从小到一个移动设备到大到一个包含企业所有账户信息的数据服务器. 幸运的是,EF可应用于WCF,WEB Api等诸如此类的多层框

ASP.NET Web API 2.1支持Binary JSON(Bson)

ASP.NET Web API 2.1内建支持XML.Json.Bson.form-urlencoded的MiME type,今天重点介绍下Bson. BSON是由10gen开发的一个数据格式,目前主要用于MongoDB中,是MongoDB的数据存储格式.BSON基于JSON格式,选择JSON进行改造的原因主要是JSON的通用性及JSON的schemaless的特性. BSON主要会实现以下三点目标: 1.更快的遍历速度 对JSON格式来说,太大的JSON结构会导致数据遍历非常慢.在JSON中,

web Api自定义部分Action的JSON格式输出

昨天项目中要部分Api的JSON格式需要特殊处理.最开始直接重写controller的JSON方法.经测试,当action直接返回数据的时候,不会调用Json方法. 然后找了各种方法,都不行.在群里问了.直到看到群友发的一个直接移除所有API的JSON格式方法的时候.图片如下: 然后就想到了Api的ActionFilterAttribute.就解决了自己的需求. 上代码.懒得写说明. 1 public class AppFilterAttribte : ActionFilterAttribute

Asp.Net Web API 2第八课——Web API 2中的属性路由

参考页面: http://www.yuanjiaocheng.net/webapi/web-api-gaisu.html http://www.yuanjiaocheng.net/webapi/create-web-api-proj.html http://www.yuanjiaocheng.net/webapi/test-webapi.html http://www.yuanjiaocheng.net/webapi/web-api-controller.html http://www.yuan

在ASP.NET Web API项目中使用Hangfire实现后台任务处理

当前项目中有这样一个需求:由前端用户的一个操作,需要触发到不同设备的消息推送.由于推送这个具体功能,我们采用了第三方的服务.而这个服务调用有时候可能会有延时,为此,我们希望将消息推送与用户前端操作实现异步执行,就是希望在后台自动执行,不阻塞前端用户的操作,而且最好能实现失败重试等功能. 经过一些研究比较,我们发现使用Hangfire这个组件可以较好地实现这个需求.为了给大家做一个演示,我这里简化了代码,做一个范例程序. 我在这里不准备详细介绍Hangfire的基本用法,有兴趣的同学们可以参考官方

使用ajax调用web Api 方法中出现的问题总结

一,Get请求 1,无参数Get请求,跟平常写ajax请求一样,并无什么差别 $.ajax({            url: '.../api/User/UserVerify,            type: 'get',            success: function (json) {                alert(json);            },            error: function () {                alert("er

ASP.NET Core Web API 集成测试中使用 Bearer Token

在 ASP.NET Core Web API 集成测试一文中, 我介绍了ASP.NET Core Web API的集成测试. 在那里我使用了测试专用的Startup类, 里面的配置和开发时有一些区别, 例如里面去掉了用户身份验证相关的中间件. 但是有些被测试的行为里面需要用到身份/授权信息. 所以本文就介绍一下在API集成测试中发送请求时使用Bearer Token作为Authorization Header的情况. 集成测试中使用Bearer Token 我这个项目里生产时使用的是Identi