我有一个uri的休息资源:
/invoices/1/invoiceitems/34
现在我必须添加一个名为invoiceitempieces
的发票项子这应该这样做:
/invoices/1/invoiceitems/34/invoiceitempieces/7
这似乎比这些选项更有条理
/invoiceitems/34/invoiceitempieces/7
/invoiceitempieces/7
我更喜欢带有所有三个ID的示例,但这是最佳/可接受的做法吗?
答案 0 :(得分:1)
最佳做法是使用 HATEOAS 。 RESTful URI是不透明的。
REST API不得定义固定资源名称或层次结构(an 客户端和服务器的明显耦合)。服务器必须具有自由 控制自己的命名空间。相反,允许服务器指示 客户端如何构造适当的URI,例如在HTML中完成 表单和URI模板,通过在媒体中定义这些指令 类型和链接关系。 [失败在这里意味着客户是 假设由于带外信息而产生资源结构,例如 特定于域的标准,它是面向数据的等价物 RPC的功能耦合]。
看到这个: http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
答案 1 :(得分:1)
虽然这似乎是最合适的概念......
/invoices/1/invoiceitems/34/invoiceitempieces/7
......你会发现它很难实现(根据我自己的经验)。你会发现这个......
/invoices
/invoices/1
/invoices/1/invoiceitems
/invoiceitems/34
/invoiceitems/34/invoiceitempieces
/invoiceitempieces/7
...同样有用且更容易实现,即使它可能不那么优雅。
答案 2 :(得分:1)
我认为您必须拥有发票项目和发票项目ID的ID和订单是唯一的,并且“订单+ invoice_id”组合是唯一的,因此您可以访问invoiceitempieces抛出2种方式
/invoices/{invoice_id}/invoiceitems/{invoiceitems_order}/invoiceitempieces/{invoiceitempieces_order}
/invoiceitems/{invoiceitems_id}/invoiceitempieces/{invoiceitempieces_order}
/invoiceitempieces/{invoiceitempieces_id}
因此,如果客户需要,您将具有灵活性并在URI“订单”中提供更多信息。