Question

在我的应用程序中，我有一个Order的概念，它是一个资源，是其他资源的集合（Draws）。（背景：How to RESTfully support the creation of a resource which is a collection of other resources and avoiding HTTP timeouts due to DB creation?）

当用户在API中创建订单时，它将提交如下所示的JSON：

{
    "order": {
      "draws": [
        {
            "background_color" : "rgb(0,0,0)", "font_size" : 14
        }, 
        {
           "background_color" : "rgb(255,0,0)", "font_size" : 16
        },
        ...
       ]
    }
}

然后，我的应用程序将向用户返回一个跟踪号，以便他可以看到该订单的当前状态，并将该JSON推送到队列，以便可以在后台处理。

但是，我有一个问题：

订单完成后，用户取回订单，我将返回一个Draws列表。像这样：

      "draws": [
        {
            "background_color" : "rgb(0,0,0)", "font_size" : 14, "url" : "generated_url"
        }, 
        {
           "background_color" : "rgb(255,0,0)", "font_size" : 16, "url" : "generated_url2"
        },
        ...
       ]

我的问题是：

用户如何知道结果中的哪个抽奖是他提交的内容的抽奖？这是我想到的两个解决方案：

1 - 当用户提交订单时，对于每个抽奖，他都会提交一个唯一的ID，因此稍后创建这些ID时，他将能够映射它们。

2 - 当用户提交订单时，我的应用程序为每个Draw创建一个唯一的id。稍后当在数据库中实际创建Draw时，我将该唯一ID放入DB中。

更合理的是，考虑到订单最多可以有100.000次抽奖。

Answer 1

嗯，请注意，您的客户已经为每个请求的抽奖分配一个唯一的ID：它们在draws数组中的位置隐含着它。因此，对抽奖＆＃34; 1＆＃34;，＆＃34; 2＆＃34;等进行编号将是多余的。

只要您的客户端和服务器都能够在不重新排序的情况下处理此数组，请求和响应中的绘制之间存在自然映射，并且我相信您已经拥有RESTful解决方案。那是假设

当客户提交订单时，服务器返回的是 URI （不仅仅是跟踪号），它指向相应的新order资源的位置。
当客户获取此订单表示时，响应包括两个订单＆＃39;处理状态及其关联的draw资源列表，每个资源都由服务器分配一个指向其表示的唯一URI（如上面的示例响应中所示）。 / p>
此时，每个抽奖的URI都成为其唯一标识符，并且通过数组之间的平凡映射，客户可以使用此信息轻松更新自己的订单表示。

为了提高效率（以及最大的RESTfulness），当客户端发布新订单时，您可能让服务器立即响应201 Created（或者可能是202 Accepted）状态并包含新订单的表示，包括新的绘制URI，在响应正文中。这样，您的客户既可以提交订单，又可以通过单次互动更新自己的响应。

Answer 2

选项＃2类似于Oreilly Books的RESTful Web Services Cookbook第47页上的解决方案。

“在接收POST请求时，创建新资源，并返回状态代码202（已接受），其中包含新资源的表示。此资源的目的是让客户端跟踪异步任务的状态。设计此资源，使其表示包括请求的当前状态和相关信息，如时间估计。

当客户端向任务资源提交GET请求时，请根据请求的当前状态执行以下操作之一：

仍在处理中返回响应代码200（OK）以及具有当前状态的任务资源的表示。

成功完成返回响应代码303（请参阅其他）和包含显示任务结果的资源的URI的Location标头。

关于任务失败返回响应代码200（OK），其中表示任务资源通知资源创建失败。客户需要阅读表示的主体以找出失败的原因。“

摘录自：Subbu Allamaraju。 “RESTful Web Services Cookbook - Subbu Allamaraju.epub。”

我应该如何以RESTful方式唯一标识POST请求资源？

2 个答案: