不持久化数据的资源

Question

JSON-API 要求我提供id 与我们创建和移动的资源。但是我们如何处理资源没有自然 ID 的情况呢？

一个很好的例子是一个报价系统，价格需要在服务器端确定。在这种情况下，我们不会给客户端提供价格手册来自行计算价格，客户端需要向 API 提交一些内容，以便服务器确定价格。

但是，我们不希望将报价保留到数据库中，因为它在技术上并未“锁定”，客户端只是在继续之前使用选项”

我想到的一种方法是为处于挂起状态的报价创建一个 UUID

例如

POST /quotes
{ "data": { "type": "quotes", "attributes": { 
    "state": "pending", <all the items> 
    } }
returns
{ "data": { "type": "quotes", "id": <UUID>, "attributes": { 
    "price": 900, "state": "pending", <all the items> 
    } }

现在我在响应中有价格，但我还不能在定义的 URL 上得到它，比如 /quote/1234。

然后，一旦状态更新为“已报价”，我就可以将其实际保存到 DB，获取正确的 ID，然后客户可以 GET /quote/1234 来查看提交的报价及其价格。

另一种方法是创建意图资源，以模拟获得价格或完成某些工作流程的意图。我只是不知道您将如何在 JSON-API 上下文中实现它，因为同样没有 ID。

应该如何处理这些动态/计算/短暂的资源端点？

Answer 1

我将为这些报价前请求创建一个单独的表。我可以想到几个原因，为什么您希望将这些捕获在数据库中，您可以拥有各种指标，例如他们使用选项的次数，在什么时间，创建实际报价需要多长时间等. 然后您可以限制这些请求，您可以停止此类请求的垃圾邮件等。

一旦预报价变成实际报价，此时您可以将数据移动到您的报价表并可以正确使用 API，因为您现在可以使用来自预报价的 ID。在我看来，如果您只是将它们存储在数据库中并从一开始就为它们分配一个正确的 ID，那么您就可以简化一切。