5

假设我有一个包含联系人详细信息资源的应用程序资源，并且联系人详细信息包含地址资源。

例如。

Application
--> Name
--> Application Amount
--> Application Contacts 
--> --> Contact 1
--> --> --> Address
--> --> Contact 2
--> --> --> Address

在对应用程序进行 POST 时，我正在创建根应用程序。对于像应用程序联系人这样的所有子资源，我做一个 POST 来创建联系人 1 等......

我的问题是，Application = 提交某处进行处理，但我不想在填写所有内容之前提交它，也就是所有子资源。

So the order of submission
1) Create Application Resource --> POST /Application --> Get ID
2) Create Contact 1 Resource --> POST /Application/id/Contacts --> Get ID
3) Create Contact 1 Address Resource --> POST /Application/id/Contacts/id/Addresses
4) Create Contact 2 Resource --> POST /Application/id/Contacts --> Get ID 
5) Create Contact 2 Address Resource --> POST /Application/id/Contacts/id/Addresses
6) DECIDE TO SUBMIT HERE <--- ?? HOW?

乔什

4

3 回答 3

2

您的设计不是 RESTful。您的资源可能与您的业务实体是一对一的映射？我不建议这样做，因为它会将您的域模型的内容暴露给外部世界，这可能会导致版本控制问题。它也使这样的问题变得比他们需要的更难——尽管你可能正在使用一个 REST 框架来强制你进行这种设计:-(。

要记住的是，REST 中的资源是您希望外部世界看到的域模型元素的抽象表示，它们很可能需要映射和转换才能转换为域对象。它们可以任意复杂。

我想说，这里的解决方案是让创建应用程序的 POST也创建联系人及其地址。然后，客户端可以提供现有联系人和地址的 URL（服务器可以取消对域对象的引用），或者在单个POST 中创建新的必要细节。然后以事务方式创建和关联实体的责任落在服务器身上。它只是返回对标识新应用程序的 URL 的引用。如果您需要知道联系人的 URL，那么您重新获取应用程序，它将包含它们。

假设您的资源是 JSON mime 类型，初始 POST 可能如下所示： 

{
    Name: "Application name",
    Amount: "123.00",
    Contacts: [
        {
            Name: "Contact name",
            Address: {
                HouseNumber: "45",
                StreetName : "Sesame Street"
            }
        }
    ]
}
Return: {href:  “/Application/6789”}

到 /Application/6789 的 GET 将返回如下内容： 

{
    Name: "Application name",
    Amount: "123.00",
    Contacts: [
        { mimeType: "application/vnd.com.myStuff.contact+json", href: "/Contact/203" }
    ]
}
于 2013-07-29T07:34:24.627 回答
0

希望我正确理解了你的问题。让我知道我是否错过了重点，并且总能带着新的东西回来。

因此，如果所有“子资源”都已从第 1 步到第 5 步创建。在每个步骤中，都应该有一个返回的ID来确认资源创建成功。像，

POST /Application
Return: {appid:  “/Application/id”}

因此，一旦第 5 步 POST 返回，就会创建最后一个资源。然后下一步是开始应用程序“处理”。

“应用处理”可以被认为是一种资源，业务行为是：“创建处理”资源和“检查处理结果”</p>

它们可以分别在“处理”资源上使用 POST 和 GET 进行建模。

创建处理资源

POST /Application/id/Processing
Return:  {processingid: “/Application/id/Processing/id”}

检查处理资源

GET /Application/id/Processing/id
Return: {processingid: “/Application/id/Processing/id”, <other info>}

要恢复整个应用程序，

GET /Application/id
Return: {all info on the application including processing status as well…}

希望这有帮助。

于 2013-07-22T17:21:38.093 回答
0

您很可能会有某种状态字段来指示申请是否已提交。在这种情况下，我会建议以下两种方法：

1) 发布到应用程序资源，并将其状态字段设置为适当的值以表明您的意图：

POST /application/654321
status=submitted...

这是菲尔丁论文的引述：

“REST 组件通过使用表示捕获该资源的当前或预期状态并在组件之间传输该表示来对资源执行操作。”

2) 将应用程序发布到特定集合 /submittedapplications，您也可以使用它通过 GET 搜索您提交的应用程序：

POST /submittedapplications
id=654321...

由于除了更新应用程序资源之外，很可能还有其他处理步骤，因此您应该使用 POST 动词来指示重复提交是不行的。

顺便说一句，这两种方法并不相互排斥，您当然可以在同一个 API 中实现这两种方法。

于 2013-07-23T00:38:33.863 回答