RESTful API排序设计：sortBy与orderBy参数方案是否最优？

这个问题问得很实在——我之前做REST API设计的时候也纠结过类似的参数命名，先给你个明确的结论：你现在采用的sortBy指定排序字段、orderBy指定排序方向的方案，是非常合理且常用的实践，完全可以作为最优方案之一。

为什么这个方案值得推荐？ #

• 语义清晰，无歧义：sortBy明确指向「按哪个属性排序」，orderBy明确定义「升序/降序的排序方向」，把排序的两个核心维度拆解得清清楚楚。网上有人说sortBy和orderBy本质相同，其实是混淆了「排序的维度」和「排序的规则」，分开命名反而让参数职责更明确，不管是前端调用还是后端维护，都能一眼看懂参数作用，几乎不需要额外解释。
• 扩展性极强：如果后续需要支持多字段排序，只需要把sortBy扩展为逗号分隔的字段列表即可，比如api/blogs?sortBy=title,createdAt&orderBy=desc,asc——这种格式在很多成熟的公开API中都有应用，兼容性和可维护性拉满。
• 符合REST设计直觉：URL参数用来传递过滤、排序这类查询修饰符是REST API的标准做法，这种命名方式也贴合大多数开发者的直觉，团队协作时学习成本极低。

其他常见方案的对比 #

当然也有一些替代写法，你可以根据团队习惯选择：

• 合并式参数：用单个sort参数把字段和方向合并，比如sort=-title（负号代表降序），这种写法更简洁，但多字段排序时可读性会下降，比如sort=-title,+createdAt，新手可能需要查阅文档才能理解符号的含义。
• 简化命名：有些团队会用order代替orderBy，本质上和你的方案逻辑一致，只是命名习惯不同，只要团队内部统一规则就没问题。

总结 #

你的方案在可读性、扩展性和直观性上都表现出色，完全可以放心使用。API参数设计的核心不是追求“绝对最优”，而是团队统一、语义明确、易于维护——你的方案刚好满足这些核心要求。

内容的提问来源于stack exchange，提问作者KTOV