Allow Customization of Default Routing Prefix for Added HTTP Endpoints #28
Closed
stephanjohnson
started this conversation in
General
Replies: 2 comments
-
This sounds like a good enhancement, I have logged it as an enhancement on our back log. Thanks for the suggestion. |
Beta Was this translation helpful? Give feedback.
0 replies
-
Hi @stephanjohnson |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
The default behavior for adding a new HTTP endpoint is to prefix the route with
api/
. This convention dates back to earlier practices when APIs were typically part of the same project as the UI. Theapi/
prefix served as a clear distinction between the API endpoints and other parts of the application, providing organized routing, easier versioning, and even assisting certain authentication scenarios.However, the landscape of software development has evolved, and it's now more common to have the backend and frontend separated into different projects, with each hosted independently. In this setup, APIs are often hosted on an
api.
sub-domain, leading to situations where theapi/
prefix on the route can appear redundant, such ashttps://api.myproject.com/api/...
.While the
api/
prefix still has its merits in certain scenarios, like namespace differentiation, versioning, and assisting certain load balancers or reverse proxies, its utility may diminish in cases where the backend is hosted on a dedicatedapi.
subdomain.To cater to these diverse modern practices, it might be beneficial to introduce an option allowing developers to customize the default routing prefix at the application level. This enhancement would enable developers to align their API configuration more closely with their specific deployment architectures and preferences, without being tied to a potentially redundant prefix.
Beta Was this translation helpful? Give feedback.
All reactions