我们有一个复杂的结构BPM解决方案。我们现在想要将结构公开为一组休息API。
我们有一个应用程序，在应用程序中我们有工作流程，工作流程可以有动作。动作有字段和字段可以有规则。
所以现在第一组字段或规则的api是
[获取] 应用/ 1 /工作流/ 1 /动作/ 1 /场/ 4 /规则
[发布]
应用程序/ 1 /工作流/ 1 /动作/ 1 /场/ 3 /规则
但这看起来不太好，这些可能会变得更复杂，通常我所读到的是尽可能保持URI尽可能简单，不应该进入那个深度。
那么上面提到的首选uri应该是什么。
我们应该将字段和规则作为单独的资源吗？或者如何去做。如果我们将它作为单独的资源，那么如何获得特定的字段。它不会需要很多参数，然后又不是一个好的方法。
再次修改
我想确认的是，如果制作我上面提到的深度URI是一个很好的标准（某些人认为这不是一个很好的方法），但正如你所提到的更像是一种选择。
那么如果我没有选择制作长URI并保持它至少适用于至少版本1，该怎么办呢。
在上面的URI示例中，我必须提供应用ID，工作流ID，操作ID和字段ID才能到达必填字段。这将保持这种方式，除非我有一些哈希来识别特定的URI。所以
apps/1/workflows/1/actions/1/fields/3/rules
成为
/55667788
如果我想保持URI可读性很小，该怎么办？
例如
Fields/返回app 1的所有字段，工作流程1操作1但是如何在不使我的URI如此混乱的情况下提供所有这些ID？保持两个级别？是可能还是我朝错误的方向走？
答案 0 :(得分：8)