json patch支持的操作，一共有6种
add：就是向资源里面添加值，或者是向数组里面添加一个元素。
开始写代码
JsonPatchDocument需要我们安装一个库
从employee映射到UpdateDto
比如说patchDocument如果有一个只读的操作，它add的一个属性，这个属性在C#类里面并不存在，这时候就会报错，或者是它要修改一个只读的属性。这些都会报错。所以说我们需要处理一下这块。
一个替换的操作replace。然后替换的字段是employeeNo。替换后的值是1111122222
422错误
这是因为asp.net core 3.0开始他是用的json库，是比较新的json库。新的库实现一些比较核心的功能。很多功能还没有实现。
下面我们就是用json.net库要替换。
再次发送请求204
查询结果EmployeeNo确实被更改了。但是出现了一个问题。查询结果变成xml的格式了
headers加上接收的类型。
但是没写Accept的headers为什么默认返回的是xml格式的呢？
因为默认用的是core自带的json库，但是后来我们加了json.net替换了 它，所以默认优先返回的就是xml格式了。
这我们把json.net的添加 到addXml的前面
这样不加accept返回的也是xml格式了。
把名字改成
再查询确实被更新了。
remove操作会把datetime类型设置成默认值
Add+copy
处理验证错误
我们先把employeeNo字段的值移除了。
返回的是500错误。也就是在Controller的model 绑定环节并没有走。
为什么没走因为这个类型是JsonPatchDocument而不是我们的UpdateDto类型。
所以在下面，我们就需要进行手动验证
若果验证失败就返回false，并且错误信息会放在ModelState里面。
ValidationProblem方法就实现了 ValidateProbleDetails的标准
jsonPatchDocument里面也可能出错。比如说我们想删除一个不存在的字段
随便传一个字段
返回500是不对的，因为是客户端引起的错误 ，应该是4开头的。
如果patchDocument里面有任何的验证错误，就会把ModelState的属性变成false，并且错误信息也会放在里面。
也把jsonPatch里面的错误指出了
处理为什么返回的是400，而不是422错误。
ValidationProblem里面返回的错误信息是手动返回的，
之前我们自定义了problemDetails的错误格式。
但是我们这里的ValidationProblem方法并没有采用startup里面配置的ProblemDetails的配置。所以它返回的是400 bad request 而不是422
而这块在model绑定的时候，那个验证才使用了下面的配置。
修改返回的格式
重写下ValidationProblem
我们最后要返回的是采用startup的配置
再次发送请求
局部更新或新增
先new 一个UpdateDto然后还是把patchDocument里面的值 放到dto里面，把modelState传过去做验证。
最后要返回的是employeeDto
测试
把id故意改成9999
返回的header里面
复制headers看看能不能获取这个值
