如果我们在REST中创建了多个具有相同请求的资源，将会对服务器端产生什么影响。 我知道使用put请求，由于幂等，我们可以实现容错。如果我们使用post而不是put，那么除了容错和缓存之外，还有其他事情可以实现。 如果我们创建了许多资源，那么性能会有问题吗？如果我们创建了许多资源，那这有什么问题呢？ 在发布之后，如果我们调用n次相同的请求，那么我们将n次访问服务器，那么创建新资源并且相同资源将不会对服务器产生影响。
答案 0 :(得分：0)
如果我们在REST中使用POST方法创建更新请求的多个资源。如果创建了多个资源，这会对服务器端产生影响。
首先，HTTP是REST的事实上的传输层，它是application protocol for transferring documents over a network，而不仅仅是您可以在其上运行业务规则的应用程序域。您通过网络发送数据推断出的任何业务规则，都只是您通过HTTP执行的实际文档管理的副作用。从文档管理到您的业务层可能会很好地映射某些瘦对象，但某些事情可能不会。即HTTP并非旨在支持更大范围的批处理。
通过这样，即使HTTP本身定义了一组methods，您也可以将IANA administering additional ones与RFC 7231一起使用，实际的实现取决于服务器本身。尽管可能不是，但它应遵循RFC中的语义概述。在这种情况下，它可能会损害与其他客户端的互操作性，因此建议遵循该规范。
请求对服务器可能产生的影响或影响取决于几个因素，例如服务器的类型，需要处理的数据以及是否可以卸载工作（例如通过缓存）以及您使用的内部基础架构。如果您的服务器支持数百个内核和TB级的地址空间，那么与要处理的请求相比，如果服务器仅具有一个CPU内核和一个GB的RAM，则对服务器的影响可能较小，它必须适合其他几个应用程序以及OS本身。通常，尽管请求对服务器的实际影响并不影响您在其核心HTTP上调用的操作，如前所述，它只是一个远程文档管理协议。某些方法（例如PATCH）可能是该规则的例外，尽管它显然需要事务支持，因为需要应用补丁文档中定义的全部或全部操作。
我知道使用put请求，由于幂等，我们可以实现容错。如果使用post代替put，会发生什么？
Jim Webber包含POST和PUT之间差异的提示：
POST和PUT方法之间的根本区别通过所附表示形式的不同意图得以突出显示。 POST请求中的目标资源旨在根据资源自身的语义处理封闭的表示形式，而PUT请求中的封闭的表示形式则定义为替换目标资源的状态。因此，即使确切的效果只有原始服务器知道，PUT的意图才是幂等的，并且对于中介者是可见的。
POST不会给客户任何关于发生网络错误时的承诺，即您可能不知道请求是否到达服务器并且仅丢失响应或实际请求是否发出它到服务器。 POST-PUT举例说明了为什么幂等很重要，尤其是在处理货币和货币时。
HTTP非常特定于通知客户端何时创建资源，方法是在响应中包含HTTP Location标头，该标头包含所创建资源的URI。这适用于POST以及PUT和PATCH。现在可以利用此前提条件来“安全地”上传数据。客户端可以向服务器发送POST请求，直到它收到带有Location标头的响应，该标头指向所创建的资源，然后该标头将在下一步中用于对该服务器执行PUT更新资源与实际内容。这种模式称为conditional requests创建模式，如果您要发送的有效负载较大或必须保证状态仅触发一次业务规则（例如，在线购买），则该模式特别有用。
请注意，在{{3}}的帮助下，也可以使用某种形式的乐观锁定，尽管这至少需要事先知道当前资源的状态，因为此处一定有一个特定的值。当前状态包含在作为分布式锁的请求中，该分布式锁与服务器当前所处的状态不同（因为与此同时其他客户端可能进行了更新）将导致该请求被拒绝服务器端。
如果我们使用post进行更新来创建大量资源，是否存在性能问题？如果我们创建了许多资源，那么对服务器有什么影响？
我不确定created a number of resources using post for update是什么意思。您是否要通过POST创建或更新资源？这些方法所承诺的语义不同。如何映射文档修改事件以触发后端中的某些业务规则完全取决于您。但是，总的来说，如前所述，HTTP在批处理方面并不理想。
如果我们将n次调用相同的请求，则在发布后放置n次，这将使服务器n次访问服务器，然后创建新资源，并且相同资源不会影响服务器。请确认此语句是对还是错
如果您通过POST向服务器发送n个请求，则服务器将执行应该对POST请求执行的逻辑n次（如果所有请求均到达服务器）。是否创建新资源取决于实现方式。 POST请求可能只会启动备份过程，某种计算或实际上什么也不做。如果已创建响应，则响应应包含一个Location头，该头的URI指向新资源的位置。
就通过PUT发送n个请求而言，如果所有这些请求都使用相同的URI，则服务器通常应将有效负载用作目标资源的新状态。如果在内部导致数据库更新，那么实施细节可能会因项目而异。通常，PUT请求不会反映在新资源的创建中，除非目标URI指向的资源以前不存在，尽管它也可能会产生更多的副作用。想象一下，如果您设计某种版本控制系统。 PUT被允许有副作用。这样的副作用可能是您在HEAD干线上执行了更新，将新状态应用于HEAD，尽管作为副作用，在提交历史记录中为该提交创建了新的资源。
因此，总而言之，您无法仅基于您使用的HTTP操作来推断请求对服务器的影响，因为HTTP只是应用程序协议，可通过网络传输文档。触发的实际业务规则只是实际文档管理的副作用。请求对服务器的影响取决于多个因素，例如您使用的服务器的类型，还取决于请求的长度以及在服务器上如何处理请求。每个可用的方法都有其自己的语义，您不应该通过它们可能对服务器产生的影响来比较它们，而是在前提条件下将它们提供给客户端。由于该方法的幂等属性，某些诸如余额或金钱之类的事情应通过PUT完成。