我正在设计一个 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
该请求将返回 meVector以及Java 类ArrayList的所有其他子类。Collection
不过，那个 URI 很长。我已经可以通过允许hs作为has-supertype. 这会给我：
GET http://example.org/api/v1/class?hs=http://example.org/api/v1/class/collection
允许较短 URI 的另一种方法是允许 URI 前缀的别名。例如，我可以class为 URI prefix 定义一个别名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 并在包 ABC 中的所有类”的思路思考（其中包也可以通过 URI 寻址http://example.org/api/v1/packages/a/b/c）