使用URI作为在REST调用的参数值的最佳实践

Question

我设计一个REST API，其中的一些资源可以通过查询参数进行过滤。在某些情况下，这些过滤器值是从同一个REST API资源。这使得稍长的和漂亮的不可读的URI。虽然这不是一个太大的问题的本身，因为这些URI是为了创建和编程方式进行操作，它使一些痛苦的调试。我想允许快捷方式用作过滤器值的URI和不知根据REST架构，如果这是允许的，如果有任何的最佳做法。

例如：

我有得到我的Java类的资源。然后下面的请求会给我所有的Java类：

GET http://example.org/api/v1/class

假设我想Collection Java类的子类，然后我会用以下请求：

GET http://example.org/api/v1/class?has-supertype=http://example.org/api/v1/class/collection

这是请求将返回我Vector，ArrayList和Collection Java类的其他所有子类。

这URI是相当长的，但。我可以通过允许hs作为has-supertype别名已缩短。这会给我：

GET http://example.org/api/v1/class?hs=http://example.org/api/v1/class/collection

的另一种方式，以允许更短的URI将允许URI前缀别名。例如，我可以定义class作为URI前缀http://example.org/api/v1/class/的别名。这将使我以下可能性：

GET http://example.org/api/v1/class?hs=class:collection

另一种可能性是将完全去除类别名，并始终前缀http://example.org/api/v1/class/参数值，因为这是我支持的唯一事情。这将开启请求Collection的所有子类型为：

GET http://example.org/api/v1/class?hs=collection

做这些原始请求URI仍然符合一个REST架构的原理的“简化”？还是我刚刚熄灭的深底？

附录： 可能有一次超过一个过滤器中的URI。也可以是不同的参数，或作为单个参数的值的列表。 沿的“所有类实现接口X和/或接口Y”的线或“实现接口X，并且在包A.B.C所有类”（其中包也将是可寻址到URI等http://example.org/api/v1/packages/a/b/c）

认为

Answer 1

我会去制作：

GET http://example.org/api/v1/class/java.util.Collection/subclasses

您的RESTful API，每个直接子类中返回的链接到其他项目列表。我想也使提供的资料，通过返回的描述符的一部分：

GET http://example.org/api/v1/class/java.util.Collection

（这也将包括一个链接到前述特定查询。）