我有一个代表进程和活动的RESTful Web服务。每个活动都在一个且只有一个流程内。 我想表示当前进程与另一个进程之间的活动“移动”操作。
我看过论坛，发现人们建议使用不太标准的MOVE操作，其他建议使用PUT但是我不知道如何区分PUT更新和PUT之间的移动哪个看起来语义错误。
有什么想法吗？
答案 0 :(得分：9)
一种方法可能是将移动本身表示为“转移”资源（转移为名词），然后POST一个新的：
POST /transfer
使用包含以下内容的实体
activity: /activities/4
toProcess: /processes/13
这样，客户端就会创建新的“传输”，在服务器上处理验证和转移活动。
这使您能够添加有关传输的信息。如果您想保留审核历史记录，可以在资源中添加transferredBy属性，或者transferredOn日期。
答案 1 :(得分：4)
如果使用PUT，您可以通过现有实体的流程是否与新实体匹配来区分。
PUT /process1/activity2
process: 2
some_data: and_stuff
逻辑响应（如果成功）
303 See Other
Location: /process2/activity2
答案 2 :(得分：1)
给出可用的答案，我对提案并不真正满意。
POST是一种通用方法，如果其他任何操作都不符合要求，则应使用该方法。接收到的有效负载的语义仅由服务/ API定义，因此可能是一个API的解决方案，而不是大多数API的解决方案。它进一步缺乏幂等性，在网络问题的情况下，它将使客户端不确定请求是否已接收到服务器以及仅响应中途丢失还是请求无法到达服务器。因此，连续的请求可能会导致意外结果或需要采取的进一步措施。
PUT的语义是用有效载荷中提供的表示替换从资源（可能为空）获得的当前表示。服务器可以自由地将接收到的表示修改为更合适的表示，或者附加或删除其他数据。 PUT甚至可能对其他资源也有副作用，即是否提供了用于文档更新的版本控制机制。在提供上述idempotency属性的同时，PUT实际上不符合所请求动作的语义。这可能会严重影响互操作性，因为标准HTTP服务器将无法正确为您提供服务器。
一个人可能会结合使用POST在新端点上创建新的表示形式，然后再通过DELETE删除旧的表示形式。但是，这是两个单独的操作，其中第一个操作可能会失败，如果处理不正确，则在最坏的情况下会导致立即删除原始资源。不幸的是，这组操作中没有真正的交易行为。
我建议使用PATCH而不是使用上述操作。 PATCH是客户计算出的将当前表示转换为所需表示的必要更改的重要部分。支持PATCH的服务器将必须自动应用这些指令。要么全部应用，要么根本不应用。 PATCH可能会有副作用，因此最适合当前在HTTP中执行移动。但是，要正确使用此方法，应使用某些媒体类型。一个人可能会以JSON Patch（more reader-friendly）为方向，尽管这仅定义了操作的语义以修改基于JSON的表示形式的状态，而没有处理多个资源AFAIK。