在REST API中，您不应该过度关注可预测的URI。URI可预测性暗示了对RESTful体系结构的误解。它假设客户端应该自己构造uri，实际上他们不应该这样做。

然而，我假设你不是在创建一个真正的REST API，而是一个“REST启发”的API(比如谷歌Drive)。在这些情况下，经验法则是“路径参数=资源标识”和“查询参数=资源排序”。所以，问题就变成了，你能在没有状态/区域的情况下唯一地识别你的资源吗?如果是，那么它可能是一个查询参数。如果不是，那么它是一个路径参数。

考虑一下“路径”这个词——到达某地的一种方式。路径参数应该描述如何到达您感兴趣的位置/资源。这包括目录、id、文件等。

/vehicles/cars/vehicle-id-1

其中vehicle-id-1为路径参数。

考虑一下“查询”这个词——我认为它是在问一个关于路径的问题，例如，我的路径是蓝色的吗，我的路径是否有100个结果。

/vehicles/cars/vehicle-id-1?color=blue&limit=100

这里color=blue和limit=100是查询参数，它们帮助描述我们在获得资源后应该做什么:过滤掉蓝色的，并将它们限制为100个结果。

示例URL: /rest/{keyword}

该URL是路径参数的示例。我们可以使用@PathParam来获取这个URL数据。

示例URL: /rest?关键词= java&limit = 10

该URL是查询参数的示例。我们可以使用@Queryparam来获取这个URL数据。

有一次我设计了一个API，主要资源是人。通常用户会请求过滤过的人，以防止用户调用/people?每次我都执行了/people/urban，后来我可以轻松添加/people/rural。此外，这允许访问完整的/people列表，如果它以后有任何用处的话。简而言之，我的推理是为公共子集添加一个路径

从这里开始:

常见查询的别名 为了使API体验对普通消费者来说更愉快，可以考虑将一组条件打包到易于访问的RESTful路径中。例如，上面的最近关闭的门票查询可以打包为GET /tickets/recently_closed

细分更有层次，更“漂亮”，但可能会有限制。

例如，如果你有一个url，有三个段，每个段传递不同的参数，通过制造商，型号和颜色来搜索汽车:

www.example.com/search/honda/civic/blue

这是一个非常漂亮的url，更容易被最终用户记住，但现在你有点被这个结构困住了。假设你想让用户在搜索中搜索所有的蓝色汽车，或者所有的本田思域?查询参数可以解决这个问题，因为它给出了一个键值对。所以你可以通过:

www.example.com/search?color=blue
www.example.com/search?make=civic

现在，您可以通过键引用值——在查询代码中使用"color"或"make"。

你可以通过使用更多的段来创建一种键值结构来解决这个问题，比如:

www.example.com/search/make/honda/model/civic/color/blue

希望这有意义。

思考这个问题的基本思路是:

URI是唯一标识资源类型的特定实例的资源标识符。像生活中的其他事物一样，每个对象(某种类型的实例)都有一组属性，这些属性要么是时不变的，要么是暂时的。

在上面的例子中，一辆车是一个非常有形的物体，它具有像制造、型号和VIN这样的属性，这些属性永远不会改变，而颜色、悬挂等属性可能会随着时间的推移而改变。因此，如果我们用可能随时间变化的属性来编码URI，我们可能会得到同一个对象的多个URI:

GET /cars/honda/civic/coupe/{vin}/{color=red}

若干年后，如果这辆车的颜色变成黑色:

GET /cars/honda/civic/coupe/{vin}/{color=black}

注意，car实例本身(对象)并没有改变——只是颜色改变了。让多个URI指向同一个对象实例将迫使您创建多个URI处理程序——这不是一个有效的设计，当然也不直观。

因此，URI应该只由永远不会改变的部分组成，并且将在资源的整个生命周期中继续唯一地标识该资源。所有可能更改的内容都应该保留给查询参数，如下所示:

GET /cars/honda/civic/coupe/{vin}?color={black}

底线——多态。