我无法弄清楚我应该如何处理转换的名称,以便在资源扩展的情况下与 RESTful API 的最佳实践保持一致。
例如,如果我想获取特定客户的所有订单,那么 URI 应该是https://api.website.com/customers/1000/orders
.
我能够使单个资源(即客户或订单)的转换变得平静(正如 Moqui 的示例应用程序文件中所演示的那样),但找不到任何可以解决资源扩展目的的示例。
我面临的问题是在根据 RESTful API 的最佳实践设计转换时。ExampleApp.xml 仅包含单个资源的示例,即示例实体。
如果我以 HiveMind 中使用的关于项目管理的数据模型为例,那么根据最佳实践,URI 应该是这样的
For fetching all Projects- https://api.website.com/projects
For fetching a Milestone for a particular Project - https://api.website.com/projects/DP/milestones/DP-MS-01 (Here, DP is the Project Id)
For fetching a Tasks of a particular Project- https://api.website.com/projects/DP/tasks/DP-1
现在,如果我在 Moqui 框架中设计 API,这就是我必须命名 URI 的方式
For fetching all Projects- https://api.website.com/projects
For fetching a Milestone of a Project- https://api.website.com/projects/DP/DP-MS-1
For fetching a Task of a Project- https://api.website.com/projects/DP/DP-1
因此,您可以看到这些 URI 令人困惑,因为我无法区分用于获取里程碑或任务的 URI。
我仍然可以通过检查路径参数(即,如果任务在路径参数中,则执行与任务相关的操作,类似地执行里程碑)来根据 RESTful API 设计的最佳实践来制作 URI。但是这种方法不是一个干净的方法,因为如果 URI 中的参数太多,它的维护就会变得困难https://api.website.com/projects/DP/milestones/DP-MS-1/tasks/DP-1/worklogs/DP-1-WL-2/party
。
这只是一个示例场景,在该场景中,我想获取为特定项目的特定里程碑中的任务添加工作日志的一方/人员。这是一种数据模型的情况,即 WorkEffort。
但是派对、客户、订单、产品等数据模型呢?对于 API 的开发者来说,设计一个 API 将成为一项极其繁琐的工作。
所以我只是问是否有另一种在 Moqui 中实现的更清洁的方法可以用作参考?