When it comes to Path selection, it is also essential to understand who else uses the paths. For instance,
/api/* requests should be directed to the API while other routes lead to the SPA.
Besides, if you serve multiple applications under the same domain, you need to split each one via URL paths. It’s also important to define the Path schemes keeping space for each application to grow with their subpaths.
Otherwise, it could lead to inconsistencies and path conflicts affecting the stability of the application.
When the application grows, you need to define paths and subpath ownership for the application for the following reasons;
- Improve developer productivity by splitting the app across multiple development teams where each owns a URL path segment.
- To efficiently communicate across teams for cross navigations.
- Quickly recognize the area in code related to the path and subpaths.
Selecting the right set of parameters is difficult with the flexibility we have. One of the best practices to follow is to keep them to primitive values like numbers and strings (better to avoid serialized or base64 encoded object, unless there is a particular need).
Besides, there are several risks when using parameters. Let’s take a look at a few examples to get an idea.
- It’s essential to classify and limit what goes as URL parameters considering security. (e.g., Using long-lived tokens shared in URL is unsafe since browser history might allow navigation.)
- Parameters that are not correctly encoded affects the stability of the application.
- Using long string parameters can affect the stability and performance (e.g., The maximum character count for URL is 2,083. When we use base64 encoded data like JWT tokens in URL, there is a chance of exceeding this).
When several developers work together in the same application, it’s essential to define path conventions and parameter guidelines for consistency. This way, we can handle any exceptions knowingly and gradually expand the policies to accommodate new patterns.
If you are yet to prepare a guideline for your team, you can learn from other URL path and parameter convention schemes. For instance, you can learn from RESTful URL and OData naming conventions even for frontend paths.
Learning from RESTful URLs
If you look at the below example, you will see many similarities with our usual frontend routing conventions.
The above example is from RESTful API resource naming conventions, which you can refer to when defining your custom style guide.
Learning from OData URIs
Similar to RESTful APIs, you could also learn from URI Conventions (OData Version 2.0). Let’s look at an example.
As you can see here, you could learn from OData, especially for paths and parameters where you need more flexibility in terms of queries. For example, suppose you are building a table with lots of filtering for your application. In that case, you can consider using some of the parameter conventions from OData for your routes to make it more flexible and standard.
However, it’s crucial to highlight that these naming conventions of RESTful URLs and OData URIs are there for a different purpose. However, you can still learn from them to define better path and parameter guidelines for your application.
As you have seen, there are many factors that we need to consider when defining URL paths and parameters for web applications. Getting to know them will help you to make better decisions defining URL paths.
So far, I couldn’t find any universal way of defining frontend URL paths and parameters for web applications. However, if you know of any standards or any other factors you feel it’s important to mention, please include them in the comments below. That would be helpful for me as well as anyone who reads the article.