The InfoMapper is being moved from hash location to path location strategy, which will solve a number of issues including allowing search engine optimization and Google Analytics to a specific resource.
An initial solution is being implemented to automatically map the hash URLs to path URLs, which will help with the initial migration. As I understand it, this replaces /# with empty string.
Additionally, there may be cases in the future where map identifier or other resources will change, resulting in URL changes. It would be great if such changes could be handled in the application routing rather than having to do a CloudFront lambda, website redirect, or other technique. This will allow the InfoMapper implementer to add a redirect whenever a resource id changes. The following is an example of possible JSON for the application configuration file. Note that the URL fragments are relative to the base-href since this needs to work with any leading subfolders for the deployment, such as latest or a version. As usual, we can talk about the specific names that are used. Maybe "route" should be used instead of "path"?
It would be even more flexible if wildcards were allowed to allow evolution of the routing design, but this is not required at the moment, for example:
The InfoMapper is being moved from hash location to path location strategy, which will solve a number of issues including allowing search engine optimization and Google Analytics to a specific resource.
An initial solution is being implemented to automatically map the hash URLs to path URLs, which will help with the initial migration. As I understand it, this replaces
/#with empty string.Additionally, there may be cases in the future where map identifier or other resources will change, resulting in URL changes. It would be great if such changes could be handled in the application routing rather than having to do a CloudFront lambda, website redirect, or other technique. This will allow the InfoMapper implementer to add a redirect whenever a resource id changes. The following is an example of possible JSON for the application configuration file. Note that the URL fragments are relative to the base-href since this needs to work with any leading subfolders for the deployment, such as
latestor a version. As usual, we can talk about the specific names that are used. Maybe "route" should be used instead of "path"?It would be even more flexible if wildcards were allowed to allow evolution of the routing design, but this is not required at the moment, for example: