我无法弄清楚我应该如何处理转换的名称，以便在资源扩展的情况下与 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 中实现，我可以用作引用？
最佳答案
在最新版本的 Moqui 框架(尚未发布，仅在 GitHub 存储库中可用，但将成为下一个版本的一部分)中，现在有一个自动实体 REST 接口(interface)来执行查找和 CrUD 操作。
它支持本问题和许多其他问题中描述的模式，对于某些示例，请参见 rest.xml 屏幕文件(处理实体 REST 请求)中的注释:
https://github.com/moqui/moqui/blob/master/runtime/base-component/webroot/screen/webroot/rest.xml
关于moqui - 在 Moqui 中设计/制作过渡时如何处理资源扩展？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/28767302/