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

我正在设计一个 REST API，其中可以通过查询参数过滤一些资源。在某些情况下，这些过滤器值可能是来自同一 REST API 的资源。这会导致 URI 过长且难以阅读。虽然这本身并不是什么大问题，因为 URI 是要以编程方式创建和操作的，但它会带来一些痛苦的调试。我正在考虑允许将 URI 的快捷方式用作过滤器值，我想知道根据 REST 架构是否允许这样做以及是否有任何最佳实践。

例如：

我有一个可以获取 Java 类的资源。然后以下请求将为我提供所有 Java 类：

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

假设我想要的所有子类CollectionJava 类，那么我将使用以下请求：

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

该请求将返回我Vector, ArrayList以及所有其他子类CollectionJava 类。

不过该 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 into:

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)

我会去做：

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

返回 RESTful API 中其他条目的链接列表，每个直接子类都有一个链接。我还将将该信息作为返回描述符的一部分提供：

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

（这还包括指向前面特定查询的链接。）