创建REST资源：撰写或分离？

假设我需要为客户创建一个货件，并且该货件需要一个地址。这两个资源都需要创建。创建REST资源：撰写或分离？

在REST设计中，哪种方法是首选？为什么？

# One request that in-lines the address. 
POST /shipments  
{ 
    "shipment": { 
    "customer_id": 1, 
    "address": { 
     "city": "Toronto", 
     ... 
    } 
    } 
}

# Two requests, first creating the address, then passing an id. 
POST /addresses 
{ 
    "address": { 
    "customer_id": 1, 
    "city": "Toronto", 
    ... 
    } 
} 

POST /shipment 
{ 
    "shipment": { 
    customer_id: 1, 
    address_id: 100 
    } 
}

来源

2014-01-17 ktusznio

这只是我的看法。但我会允许这两种方法。要做到这一点，我会使用两种不同的媒体类型。但是，如果您只使用application/json媒体类型，仍然可以同时允许这两种媒体类型。

大多数语言都有automatic de/serializers从json到模型对象和回来。但是YMMV。

虽然这两种媒体类型的方法是可选的，并且有很大的影响（因为您需要使用特定的媒体类型来代替application/json）我更喜欢明确。它允许提前丢弃请求（头部首先到达服务器和客户端）。

但是，如果您问是否有任何“首选”的方式，它不是AFAIK。一个节省您（或客户端）的请求和网络往返，但另一个更清楚地说明您的API的结构。

来源

2014-01-17 20:19:09 ssedano

从您的描述中，您想操纵/管理两个“REST”资源：货件和地址。

您也是暗示的地址是在装运子资源

用例1：来创建地址信息装运

POST /shipments/ 
BODY: {address {<<address info}} 
RETURN: {shipment-id}

用例2 ：创建没有地址信息装运

POST /shipments/ 
BODY: {} 
RETURN: {shipment-id}

用例3：更新与地址信息装运

PUT /shipments/[shipment-id]/address/ 
BODY: {address {<<address info}}

用例4：，如果你有使用情况单独创建的地址，你可以有

POST /addresses/ 
BODY: {address-info} 
RETURN: {address-id}

用例5：就可以更新地址标识装运，

PUT /shipments/[shipment-id]/address/ 
BODY: {address–id {id-} }

来源

2014-01-17 21:37:28

它第一款T的认为是非常重要的他的业务和可用性影响，然后使用RESTful设计实践来实现合理的解决方案。

在您的示例中，如果您仅实施用于创建装运和嵌入地址的单独REST调用，则应用程序开发人员将无法以原子方式创建装运。如果创建的货件成功，然后创建地址失败或网络连接丢失，则最终的后端数据不完整。即使应用程序开发人员能够回滚更改，也会增加应用程序设计的复杂性。

因此，对于创建，我会允许将地址包含在货件中，或者如果没有地址的货件违反了您的业务规则，则强制将其包括在内。其他决定（例如，是否创建单独的更新请求或同时更新所有货件字段或支持两者）通常也会由业务规则和应用程序设计提出建议。

来源

2014-01-18 05:16:28

相信任何现代公共API（假设您的API是公开的）设计应该从最常见的用例中得到，而不是从代码的内部结构。即你的API应该尽可能的用于那些用例。可测试性和内部结构也很重要，但可用性更重要，因为开发人员（实际上是您服务的客户）比使用复杂的内部设计的API的易用性更容易使用API。

所以，我认为，除非您为您的API提供一组最常见的用例，否则不可能为您的问题提供某些答案。然后，你应该考虑询问那些对你的API一无所知的开发者他们是否愿意完成这些用例。最常见的答案将显示最佳方法。

来源

2014-02-03 15:17:46 DenisL

创建REST资源：撰写或分离？

回答

相关问题