1

我有一个带有 uri 的休息资源：

/invoices/1/invoiceitems/34

现在我必须添加一个名为 invoiceitempieces 的发票项的子项

是否应该这样做：

/invoices/1/invoiceitems/34/invoiceitempieces/7

这似乎比这些选项更有条理

/invoiceitems/34/invoiceitempieces/7
/invoiceitempieces/7

我更喜欢所有三个 ID 的示例，但这是最佳/可接受的做法吗？

4

3 回答 3

1

虽然这似乎是最合适的，但从概念上...

/invoices/1/invoiceitems/34/invoiceitempieces/7

...您会发现实施起来相当困难（根据我自己的经验）。你会发现这...

/invoices
/invoices/1
/invoices/1/invoiceitems
/invoiceitems/34
/invoiceitems/34/invoiceitempieces
/invoiceitempieces/7

...同样有用且更容易实现，尽管它可能不那么优雅。

于 2013-04-29T19:40:00.650 回答
1

最佳做法是使用HATEOAS。RESTful URI 是不透明的。

REST API 不得定义固定的资源名称或层次结构（客户端和服务器的明显耦合）。服务器必须可以自由控制自己的命名空间。相反，允许服务器通过在媒体类型和链接关系中定义这些指令来指导客户端如何构建适当的 URI，例如在 HTML 表单和 URI 模板中完成。[这里的失败意味着客户端由于带外信息而假设资源结构，例如特定于域的标准，它是面向数据的等价于 RPC 的功能耦合]。

看到这个： http ://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

于 2013-04-29T19:14:16.473 回答
1

我认为您必须拥有发票项目的 ID 和订单，并且 invoiceitempieces id 是唯一的，并且“order+invoice_id”组合是唯一的，因此您可以通过 2 种方式访问​​ invoiceitempieces

/invoices/{invoice_id}/invoiceitems/{invoiceitems_order}/invoiceitempieces/{invoiceitempieces_order}
/invoiceitems/{invoiceitems_id}/invoiceitempieces/{invoiceitempieces_order}
/invoiceitempieces/{invoiceitempieces_id}

因此，如果客户需要，您将具有灵活性并在 URI“订单”中提供更多信息。

于 2013-04-30T05:50:37.230 回答