为何约定式路由在RESTful API URI模式中效率更低?
Great question! Let’s break down why convention-based routing often ends up being less efficient than a RESTful URI pattern—covering both runtime performance and day-to-day developer productivity.
1. Redundant URI Structure & Unnecessary Parsing Overhead
Convention-based routes typically bake implementation details (like controller names or action verbs) into the URI, e.g., /user-controller/get-user/123 instead of the RESTful /users/123.
- Longer URIs mean more data transferred with each request, which adds up at scale.
- Server-side routing engines have to parse extra segments (like
user-controllerorget-user) to map the request to logic. This often involves more complex regex matching or rule traversal compared to RESTful routes, which prioritize resource hierarchy over implementation specifics.
2. Cognitive Overload & Higher Error Rates
RESTful URIs rely on HTTP methods (GET, POST, PUT, DELETE) to define actions, keeping URIs focused on resources. Convention-based routing forces developers to memorize additional rules:
- Is the action named
get,fetch, orretrieve? - Does the controller use singular (
user) or plural (users) naming? - Do we include an action for every CRUD operation, even when HTTP methods already cover them?
I’ve seen teams waste hours debugging frontend calls because someone used /users/fetch/456 instead of the agreed-upon /users/get/456—a mistake that never happens with RESTful GET /users/456.
3. Inflexible Scaling & Maintenance
As APIs grow, convention-based routes become unwieldy:
- Adding nested resources (like user posts) might require new controller-action combinations, e.g.,
/user-controller/get-user-posts/123instead of the clean RESTful/users/123/posts. - Every new resource or action means updating routing conventions and ensuring the entire team adheres to them. RESTful patterns, by contrast, scale naturally with resource hierarchies—no new rules needed, just extend the URI path to reflect relationships.
4. Redundant Action Semantics
Convention-based routes often duplicate the intent of HTTP methods. For example:
POST /user-controller/create-uservs. RESTfulPOST /usersDELETE /user-controller/delete-user/789vs. RESTfulDELETE /users/789
This redundancy creates two problems:
- Server-side code has to handle both the URI action and HTTP method, increasing the risk of inconsistencies (e.g., a
GETrequest to/user-controller/delete-userthat accidentally deletes data). - It bloats the routing rule set, making it harder to audit and maintain.
5. Poor Alignment with REST Principles
REST is built around resource-centric design, which convention-based routing undermines by prioritizing implementation logic over resource identity. This misalignment makes APIs harder to integrate with tools (like API gateways or client SDKs) that expect RESTful semantics, leading to extra work to adapt non-standard routes.
内容的提问来源于stack exchange,提问作者Rock Shan

