使用不完整的重新presentations PUT方法 [英] Using the PUT method with incomplete representations

问题描述

什么是从PUT预期与资源的不完全重新presentation标准的行为？

What is the standard behavior expected from a PUT with an incomplete representation of the resource?

比如说，我有一个用户在 / API /用户/ 1 这是再presented通过下面的HAL JSON：

For instance, I have a User at the /api/users/1 that's represented by the HAL json below:

{'id': 1,
 'username': 'joedoe',
 'email': '[e-mail]',
 'password_hash': '9039dmk38f84uf4029i339kf32f0932i',
 'last_visit': '2013-11-04 21:09:01',
 'public': true,
 '_links': {'self': {'href': 'http://foo.bar.com/api/users/1'}}

}

然后，我做一个PUT请求修改用户名和电子邮件，以重新presentation失踪其他属性

Then, I make a PUT request to change username and email, with a representation missing the other attributes:

PUT /api/users/1

{'username': 'joeydoey',
 'email': '[e-mail]'}

到现在为止，我一直认为这应该被视为一个错误，因为它意味着部分更新，但这个答案让我想起了它，它是有道理地说，一个不完全的重新presentation仍是给予的服务器随意填补空白与默认的完全替代。

Up till now, I always assumed this should be treated as an error, because it implies a partial update, but this answer got me thinking about it, and it makes sense to say that an incomplete representation is still a complete replacement that's giving the server liberty to fill in the blanks with defaults.

我无法找到任何东西，我可能会涉及到这个在HTTP标准，所以我要问，什么是在标准行为有望在这种情况下？

I can't find anything that I could relate to this on the HTTP standard, so I have to ask, what's the standardized behavior expected in this case?

1. 应该产生一个错误，因为它意味着部分更新。通过PUT有效载荷的模式应该是相同的同一个GET到相同的资源和媒体类型检索所述一个

1. It should result in an error, because it implies a partial update. The schema of the PUT payload should be identical to the one retrieved with a GET to the same resource and media type.

应该成功，因为服务器是免费的默认值是媒体类型，以填补空白。在这种情况下，将在密码重置为空白或默认的密码，并相应地刷新散列，并且LAST_VISIT和公开值设置为默认值。此选项使得很多更有意义，当你考虑HATEOAS，如果客户提交由服务器返回相同的媒体类型，因为它不能predict超媒体的控制将如何改变，重新presentation是每一次不完整的客户端不发送所有超链接，服务器必须相应地进行重置。

It should succeed, because the server is free to fill the blanks with the defaults for that media type. In this case, it would reset the password to a blank or default password and refresh the hash accordingly, and set the last_visit and public values to defaults. This option makes a lot more sense when you consider HATEOAS, if the client is submitting the same media-type returned by the server, since it can't predict how the hypermedia controls will change, the representation is necessarily incomplete every time the client isn't sending all hyperlinks, and the server must reset them accordingly.

1和2都有效，因为没有规范的行为，它是由媒体类型来决定用它做什么。这感觉不对，因为PUT不服从于资源本身，而替换它。

Both 1 and 2 are valid, because there's no standardized behavior and it's up to the media type to decide what to do with it. This doesn't feel right because a PUT is not subordinated to the resource itself, but rather replaces it.

请记住，我不要求什么感觉对还是情理之中的事情。我问其中一个是由标准的支持。

Keep in mind that I'm not asking what feels right or what makes sense. I'm asking which one is backed by the standards.

推荐答案

只要PUT的结果是从资源的客户了解一个完整的替代（即，这些属性的previous值未通过不影响PUT后的值），它应该会成功。但是，它确实使它有点混乱来看待，因为许多人都拐弯抹角这种使用PUT与字段级更新语义（而不是完全替代）的倾向。

As long as the result of the PUT is a complete replacement from the client's understanding of the resource (i.e., the previous values for those properties not passed do not influence their value after the PUT), it should succeed. However, it does make it a bit confusing to look at, since so many people have a tendency to equivocate this use of PUT with field-level update semantics (rather than complete replacement).

虽然在技术上没有休息的限制违反了这里，它可能是一个更好的主意在所有的值传递而不是诉诸于服务器默认值，因为这将有助于preserve向前兼容性。缺省值可以随时间而改变，因此，通常它们应避免使用。

While there's technically no violation of REST constraints here, it's probably a better idea to pass in all values and not resort to server defaults, because that will help preserve forward compatibility. Defaults can change over time, so generally they should be avoided.

您的联系例子，但是，是不是指没有通过默认值，所以它不是一个很好的例子不完全重新presentation。相反，链接是不是资源到服务器的客户端的重presentation的一部分。我觉得你把另一个概念混进去的位置：这是的只有的从服务器到客户端返回的属性。这是我这引发这个职位的其他线程上议论纷纷。

Your example of links, however, is not referring to not passing defaults, so it's not a good example of an "incomplete representation." Rather, links aren't part of the client's representation of the resource to the server. I think you're bringing another concept into the mix here: properties which are only returned from the server to the client. This is what I was talking about on the other thread which sparked this post.

我说的是不是一个不完整的重presentation;这是一个不同的再presentation。你是真的处理两个不同的媒体类型（即重presentations）描述相同的资源。一是从客户（我们称之为应用程序/ vnd.example.api.client），并从服务器（应用/ vnd.example.api.server）其他起源起源。他们可能不被明确地打成这样，但这是至少的隐的发生了什么。因此，由于它们是两个不同的媒体类型，它们的前preSS关于不同的东西的相同的资源

What I am talking about is not an incomplete representation; it's a different representation. You are really dealing with two different media types (i.e., representations) describing the same resource. One originates from the client (we'll call it application/vnd.example.api.client), and the other originates from the server (application/vnd.example.api.server). They may not explicitly be labeled as such, but that's at least implicitly what's happening. Therefore, since they are two different media types, they express different things about the same resource.

既然你提到HAL，认为这是一个客户端通常不POST媒体类型的应用程序/ HAL + JSON的信息到服务器。看看从HALTalk 的注册相对的一个例子。预期的内容类型是application / JSON，而不是应用程序/ HAL + JSON。而且，如果你看一下例子后，有关于它没有HAL十岁上下。没有任何联系，没有嵌入对象，等等。但是......如果你再拿到URL从这个职位返回Location头返回，它会假设你的客户接受过HAL JSON，返回类型application / HAL + JSON的响应（即与链接的用户）。两种不同的媒体类型，同一资源的两个不同重新presentations。

Since you mentioned HAL, consider that a client doesn't usually POST a message of media type application/hal+json to the server. Take a look at the signup rel from HALTalk for an example. The expected content type is application/json, not application/hal+json. And, if you look at the example post, there is nothing HAL-ish about it. No links, no embedded objects, etc. But... if you then GET the URL returned from the Location header returned from this POST, it will, assuming your client accepts HAL over JSON, return a response of type application/hal+json (i.e., a user with links). Two different media types, two different representations of the same resource.

因此​​，让我带装点接受和Content-Type头的例子来说明我的观点。

So let me decorate your example with Accept and Content-Type headers to illustrate my point.

请求

PUT /api/users/1 HTTP/1.1
Content-Type: application/vnd.example.api.client+json

{'username': 'joeydoey',
 'email': '[e-mail]'}

响应

200 OK
Content-Type: application/hal+json;profile=application/vnd.example.api.server

{'id': 1,
 'username': 'joeydoey',
 'email': '[e-mail]',
 'password_hash': '9039dmk38f84uf4029i339kf32f0932i',
 '_links': {'self': {'href': 'http://foo.bar.com/api/users/1'}}
}

大多数系统不会去这一数额的细节来描述他们的媒体类型。通常它只是框架在一个更通用的类型（如应用/ JSON或只有一个自定义的媒体类型）。然而，这一切都不改变这一事实，而这是相同的底层资源，这是两个不同的重新presentations。有意义吗？

Most systems don't go to this amount of detail to describe their media types. Usually it's just framed in a more generic type (like application/json or only one custom media type). However, none of this changes that fact that while it is the same underlying resource, these are two different representations. Make sense?

这篇关于使用不完整的重新presentations PUT方法的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！