Rest URL矩阵参数与路径参数

我有一个用于查询多维数据的RESTAPI，维度可以根据所查询的数据而变化，但是为了这个示例，让我们假设有国家、指标和性别。用户可以查询任何（或无）维度，对于每个维度，用户可以提供一个或多个值：

我需要设计一个可以接受键值对的API，我最初的设计是：

但是，最佳实践告诉我，资源应该是路径参数，因此如下所示：

然后我找到了矩阵参数，所以可能是：

我想的问题是，对于这个用例路径参数或矩阵参数，什么更好？

---

矩阵参数不是w3标准的官方部分，但它是否比使用Path有优势。我可以想到HTTP 304（因为矩阵参数的顺序应该是不相关的），我还没有真正看到路径参数被用作在路径段中提供一个或多个过滤器的方法（即两个/之间的所有东西）。

我想你应该问的第一个问题是，你在建模什么？通过查看您的示例，我还不清楚这一点

您似乎拥有

data

类型的数据，并且该数据的标识符是

providerA

。如果这对API的用户来说是一个有意义的资源，我们会很好，但也许会更具描述性

---

我知道有些人主张使用类似于第二个示例的“路径参数”，但对我来说，这种语法非常奇怪，因为

data

和

providerA

之间的路径段没有有效名称

路径参数在URI模板中使用占位符，例如

{name}

中：

/myapi/data/{name}

现在，如果这个“数据提供者”资源表示可以选择按国家、指标和性别筛选的内容，我将使用查询参数

另一方面，如果这些参数真的代表同一资源的不同维度，我会将其建模为矩阵参数

/myapi/data;country=UK,FR,DE;sex=M;indicator=X/providerA

（注意，矩阵参数可能应该用逗号分隔，而不是用空格编码的空格字符分隔）

我认为矩阵参数为它们所连接的路径段定义了不同的命名空间

---

矩阵参数附加到路径段，因此下面的示例

/widget;brand=acme/12345/image;type=packshot

。。。应理解为“acme品牌小部件12345的packshot类型图像”。不管REST教条如何，它可能比标记在末尾的查询字符串更具可读性，也更易于解释：

/widget/12345/image?brand=acme&type=packshot