如何组织REST API?

时间:2012-09-26 12:48:18

标签: api rest

我正在为我们的业务系统开发一个rest API。到目前为止,我们有以下资源:

/sales/orders
/sales/orders/{orderno}
/sales/order-items

API完成后会有很多资源,因此我们需要以良好的方式构建它以使其易于理解。我的问题是:/sales/order-items应该是/sales/orders/order-items吗?这里可能没有正确答案,但你更喜欢什么?

还有一个问题:sales/order-items资源会列出所有未清项目或所有已发货项目。无论状态如何(打开/发货), 都无法获得所有订单商品。资源URI可以是这样的sales/order-items?orderstatus={OPEN/SHIPPED}(orderstatus查询参数将是必需),或者它可以是两个资源,例如sales/order-items/opensales/order-items/shipped。什么是首选?

1 个答案:

答案 0 :(得分:1)

资源是'可以命名的任何信息'。您的URI应该是基于实体的。 'order-items'不是实体,而是数据类型。

/sales/order/order-1456321是您最想要的实体。哪个包含所有订单商品的数据。

如果您希望限制访问,则可以在未提供查询字符串的情况下返回客户端错误。

/sales/order/order-12345?status=open

等。希望这会有所帮助。

编辑:

/sales/order-items or /sales/orders/order-items?

这是特定于域的,确实应该由域专家来回答。您的URI层次结构为您的资源提供范围(以及详细信息)。因此,作为一种有根据的猜测,在“/ sales / orders /”范围内拥有“订单商品”是没有意义的,因为“订单商品”不是“订单”。

/sales/ordered-items 

似乎是最明智的答案。

在个人信息中,不要过多地质疑您的域名,对业务流程和存储的信息有深刻理解可能会产生与这些建议相似的内容;

/sales/orders?status=open - Are all orders shipped at once?
/sales/orders/order-1234/packages?status=open - Are orders split into packages?