我正在设计我的第一个Web API，而且我很难确定URI的命名方案。
API不会解决实际资源问题，而是使其接受查询，在查询字符串上运行某些逻辑，累积来自不同其他API的相应结果，或者再次对累积结果运行某些逻辑，然后返回结果
我已经开始设置存在的单个GET，如下所示（在JSON中返回“result”对象）。
api.example.com/query?string=foo&otherparam=bar
但是，我不确定这是否遵循最佳做法。
我开始认为，为了遵循API设计的最佳实践，端点名称实际上不应该是query，它应该是result，但实际上我并不是有资源，这有点违反直觉。
所以问题1 将是：api.example.com/result是更好的端点名称吗？
这是指语义URL。请考虑Wikipedia: Semantic URLs中的以下示例。
非语义网址：
http://example.com/products?category=12&pid=25
语义网址：
http://example.com/products/12/25
适用于我的案例的语义网址：
http://api.example.com/result/foo/bar
这是非常符合逻辑的，如果您拥有可查找的实际资源，则效果很好。但是，在我的情况下，参数 string 是查询字符串，参数 otherparam 是描述查询字符串属性的布尔值。
所以问题2 确实如此：如果对问题1的回答是“是”，那么在我的情况下，语义化网址应该是什么：
http://api.example.com/results/foo/bar？http://api.example.com/results/foo?otherparam=bar？（results应该是复数，因为它描述了可能的结果列表。）
答案 0 :(得分：0)
不，我认为result不是一个好的端点名称。此外，result是超级通用的，并不代表任何东西。
当我设计API时，端点可以是资源，也可以是对资源的操作
https://api.example.com/accounts/1/authorize - 此处的资源为accounts，操作为authorize https://api.example.com/search - 此处的资源将是整个平台，因此可以返回任何资源，操作为search 那么您可以将任何类型的资源附加到query操作吗？或者听起来这种类型的端点更适合你？
https://api.example.com/logic/run