Six Factors for Better URL Path Design in Web Apps

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.

  • 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.

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).

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

http://api.example.com/devices/managed-devices 
http://api.example.com/devices/managed-devices/:device-id
http://api.example.com/user-management/users/
http://api.example.com/user-management/users/:id

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

https://services.odata.org/OData/OData.svc/Category(1)/Products?$top=2&$orderby=name

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.

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.

Cheers!

Author: admin

Leave a Reply

Your email address will not be published.