代码之家  ›  专栏  ›  技术社区  ›  Mike

不允许部分卖出的理由是什么?

  •  16
  • Mike  · 技术社区  · 16 年前

    为什么http put请求必须包含一个“完整”状态的表示,而不能只是一个部分?

    我知道这是现有的Put的定义-这个问题是关于为什么会这样定义的原因。

    即:

    防止部分看跌有什么好处?

    为什么阻止等幂部分更新被认为是可接受的损失?

    4 回复  |  直到 11 年前
        1
  •  14
  •   Jan Algermissen    16 年前

    put意味着http规范将其定义为什么。客户机和服务器不能改变这一含义。如果客户机或服务器使用了与其定义相矛盾的put,则至少可能会发生以下情况:

    根据定义,put是等幂的。意思是客户(或中介!)可以重复放置任意次数,并确保效果相同。假设中介从客户机收到一个put请求。当它将请求转发到服务器时,存在网络问题。中介机构根据定义知道,它可以重试put,直到成功为止。如果服务器以非等幂的方式使用put,这些潜在的多个调用将产生不期望的效果。

    如果要进行部分更新,请对子资源使用patch或use post并返回303 see other to the‘main’resource,例如。

    
    POST /account/445/owner/address
    Content-Type: application/x-www-form-urlencoded
    
    street=MyWay&zip=22222&city=Manchaster
    
    
    303 See Other
    Location: /account/445
    

    编辑:关于部分更新不能等幂的一般问题:

    部分更新通常不能是等幂的,因为等幂依赖于媒体类型语义。注意,您可以指定一种允许等幂补片的格式,但不能保证每种情况下补片都是等幂的。由于方法的语义不能是媒体类型的函数(出于正交性原因),因此需要将修补程序定义为非幂等的。和put(定义为幂等)不能用于部分更新。

        2
  •  -2
  •   jldupont    16 年前

    因为,我猜,当多个并发客户机访问状态时,这会转换成不一致的“视图”。据我所知,rest中没有“部分文档”语义,而且在并发上下文中处理该语义的复杂性面前添加该语义的好处可能不值得这么做。

    如果文档很大,没有什么可以阻止您构建多个独立的文档,并且有一个将它们联系在一起的总体文档。而且,一旦收集了所有的比特和片段,我想可以在服务器上整理一个新文档。

    所以,考虑到人们可以“解决”这个“限制”,我可以理解为什么这个特性没有成功。

        3
  •  -2
  •   Franci Penov    16 年前

    简短回答: Put操作的酸度和更新实体的状态。

    长答案:

    RFC 2616:第2.5段,“POST方法要求将所附实体作为所请求URL的新下属接受”。第2.6段,“put方法要求将所附实体存储在指定的url”。

    因为每次执行post时,语义都是在服务器上创建一个新的实体实例,post就构成一个acid操作。但是,如果服务器已经没有足够的存储空间来存储需要创建的新实例,那么在主体中用同一个实体重复同一个post两次仍然可能导致不同的结果,因此post不是等幂的。

    另一方面,有更新现有实体的语义。即使部分更新是等幂的,也不能保证它也是acid,并导致一致且有效的实体状态。因此,为了确保酸度,put语义要求发送完整的实体。即使这不是http协议作者的目标,put请求的等幂性也会作为尝试强制acid的副作用而发生。

    当然,如果http服务器对实体的语义非常了解,那么它可以允许部分put,因为它可以通过服务器端逻辑确保实体的一致性。但是,这需要数据和服务器之间的紧密耦合。

        4
  •  -2
  •   rakslice    11 年前

    对于完整的文档更新,很明显,在不知道特定api的任何细节或它对文档结构的限制的情况下,更新后的结果文档是什么。

    如果已知某个方法永远不会是部分内容更新,并且某人提供的api只支持该方法,那么使用该api的人必须做什么才能将文档更改为具有给定的有效内容集,这一点总是很清楚的。

    推荐文章