Description

Name all routes to create flexibility in testing and future configuration.

Related Issues

refs #266

Additional Notes

Naming our routes gives us the ability to remove hardcoded paths in our routing test cases, which opens the door for future flexibility in our API route paths. A couple of places where this could be useful

• In our roadshow demo, we are planning on serving the UI from the root path (eg /, /wizard, etc). This would conflict with our API routes, so adjustments may need to be made in some environments.
• NBS has requested the desire to change their routes to align with routing standards in their K8 cluster (eg / -> /recordlinker/api). If we want to give users the ability to adjust this through configuration, it'll be best to keep our routing paths in our test cases dynamic so it will work with these new settings.

<--------------------- REMOVE THE LINES BELOW BEFORE MERGING --------------------->

Checklist

Please review and complete the following checklist before submitting your pull request:

• I have ensured that the pull request is of a manageable size, allowing it to be reviewed within a single session.
• I have reviewed my changes to ensure they are clear, concise, and well-documented.
• I have updated the documentation, if applicable.
• I have added or updated test cases to cover my changes, if applicable.
• I have minimized the number of reviewers to include only those essential for the review.

Checklist for Reviewers

Please review and complete the following checklist during the review process:

• The code follows best practices and conventions.
• The changes implement the desired functionality or fix the reported issue.
• The tests cover the new changes and pass successfully.
• Any potential edge cases or error scenarios have been considered.