当前位置: 首页 > 知识库问答 >
问题:

REST和null中的补丁

邹修真
2023-03-14

我们有一个属性为的文章资源:

  • 标题
  • 图像
  • 描述: __________
  • 状态:已发布|草稿

如果我们只想删除图像,我们提出请求

{title: null, image: null, description: null, status: null}

如果我们只想更新状态,我们会提出请求

{title: null, image: null, description: null, status: draft}

但在这种情况下,图像也将被删除。

如何在REST中只更新一个属性?

共有2个答案

戎志勇
2023-03-14

让我举一个例子,当在 RESTFul API 的补丁消息中使用 JSON 补丁消息时,这让我感到困扰。如果我们有这样的结构:

{"books": [
   {"title": "HTTP-Protocol", "image": "http.jpg", "description": "A standard book on HTTP", "status": "Available"},
   {"title": "JSON-Patch", "image": "patching.jpg", "description": "Explanation on how to use json-patch in RESTFul", "status": "Planned"},
   {"title": "RESTFul", "image": "fielding.jpg", "description": "Representational state transfer", "status": "Available"}
]}

现在请求此信息的客户端希望将第三本书(RESTFul)的状态从“可用”更改为“已借”。使用JSON-Patch,他将发送以下消息:

[
    {
        "op": "replace",
        "path": "/books/2/status",
        "value": "Borrowed"
    }
]

这意味着从列表中,正如他所见,他想更改第三项的状态。但是由于RESTFul API调用是无状态的,服务器不再知道它给客户端的列表是什么。也许同时添加了一本新书,服务器上的列表更改为:

{"books": [
   {"title": "HTTP-Protocol", "image": "http.jpg", "description": "A standard book on HTTP", "status": "Available"},
   {"title": "In between", "image": "destroy.jpg", "description": "Not RESTFul?", "status": "Available"},
   {"title": "JSON-Patch", "image": "patching.jpg", "description": "Explanation on how to use json-patch in RESTFul", "status": "Planned"},
   {"title": "RESTFul", "image": "fielding.jpg", "description": "Representational state transfer", "status": "Available"}
]}

那么从客户端收到的这个json-patch消息将改变标题为“JSON-Patch”的书,而不是客户端想要的标题为“RESTFul”的书。

你认为这个问题的解决办法是什么?

宋运锋
2023-03-14

PATCH方法可用于对资源执行部分修改。请求有效负载应该包含一组说明如何修改资源的指令。请参阅RFC 5789中的以下引用:

2.PATCH方法

PATCH 方法请求将请求实体中描述的一组更改应用于由请求 URI 标识的资源。[...]

PUTPATCH 请求之间的差异反映在服务器处理封闭的实体以修改由请求 URI 标识的资源的方式上。在 PUT 请求中,包含的实体被视为存储在源服务器上的资源的修改版本,客户端请求替换存储的版本。但是,使用 PATCH,随附的实体包含一组说明,描述应如何修改当前驻留在源服务器上的资源以生成新版本。[...]

要描述这样一组指令,您可以使用RFC 6902中定义的JSON补丁:

1.简介

json补丁是一种格式(由媒体类型< code > application/JSON-Patch JSON 标识),用于表达应用于目标JSON文档的操作序列;它适合与HTTP PATCH方法一起使用。

在其他需要对JSON文档或具有类似约束的数据结构进行部分更新的情况下,此格式也可能有用[…]

要更新状态,您可以执行以下操作:

PATCH /articles/1 HTTP/1.1
Host: example.com
Content-Type: application/json-patch+json

[
  { "op": "replace", "path": "/status", "value": "draft" }
]

使用以下命令删除该映像:

PATCH /articles/1 HTTP/1.1
Host: example.com
Content-Type: application/json-patch+json

[
  { "op": "remove", "path": "/image" }
]

并使用以下命令更新状态并删除图像:

PATCH /articles/1 HTTP/1.1
Host: example.com
Content-Type: application/json-patch+json

[
  { "op": "replace", "path": "/status", "value": "draft" },
  { "op": "remove", "path": "/image" }
]

作为JSON Patch的替代方案,您可能需要考虑在RFC 7396中定义的JSON Merge Patch:它也是一种描述对目标资源内容的一组修改的方法。

 类似资料:
  • 我有一个需求,其中我必须在POST、PATCH和PUTendpoint中具有自定义业务逻辑。使用SDR事件是不可能的,因为我需要在请求中执行一些事务操作。因此,我决定为通过服务类附加到存储库的实体创建自定义endpoint。 现在我面临一个问题,我的POST请求可能与其他实体有关联链接。SDR的默认实现可以优雅地处理这一点,但我面临杰克逊映射错误。 因此,我查找了Spring的实现方式,并找到了以

  • 使用JSONAPI1.0标准设计API,没有PUT方法。只有用于创建资源的POST方法和用于部分更新的修补程序。我们有这样的用例:用户可以向服务器发送请求,如果资源不存在,则必须创建资源,否则必须更新资源。RFC将这种方法描述为PUT。接下来引用提到的RFC5789标准补丁有信息: “如果Request-URI没有指向现有资源,服务器可能会创建一个新资源,具体取决于补丁文档类型(是否可以在逻辑上修

  • 我是否应该将我的终点设计为 或

  • 问题内容: 我刚开始使用Spring DI,但是我在依赖注入方面苦苦挣扎,更糟糕的是,我什至不确定为什么对我来说似乎还可以。希望你们能帮助我! 问题是注释为@Autowired的属性始终为null 我有一些具有Maven结构的项目: com.diegotutor.lessondeliver com.diegotutor.utility 我正在通过Tomcat 7运行示例 我在我的使用以下依赖项:

  • 好了,前面的章节解释了使用Kotlin代码完美地工作。但是与普通的Java库和Android SDK会发生什么呢?在Java中,所有对象可以被定义为null。所以我们不得不处理大量潜在的在现实中不可能是null的null变量。这意味着我们的代码最后可能会有几百个!!操作符,这绝对不是一个好的主意。 当我们去处理Android SDK时,你可能看见所有Java方法的参数被标记为单个的!。比如,Jav

  • 我正在开发两个REST API,它在我的后端编辑和暂停一些东西。对于编辑,我使用的是: 什么是最好的方法开发暂停视频服务。我应该为此使用还是?输入将只是ID。如果我使用,那么如何区分编辑和暂停呢?如果我有另一个API需要开发,例如:视频重启,我如何在REST API中容纳这些动词?