The configuration of the api_gateway_base_path assumes the input that is not already prefixed with a "/" (forward slash character). This causes consumers of the library to constantly have to modify if their base path should have the prefix added or not, and unnecessarily restricts the consumer of the library. This behavior can be improved by only prefixing the input value if it is not prefixed already.
Typically, most URI routing path parts are standardized around that format (ex: "/api/vi"). I realize that the api_gateway_base_path parameter was designed to use with "stages" in AWS API Gateway, but there are a ton of other proxy implementations that could utilize that field. Having the field "just work" by allowing it to handle both values with the prefix or not would make the library much easier to use in the long term.
The configuration of the
api_gateway_base_pathassumes the input that is not already prefixed with a "/" (forward slash character). This causes consumers of the library to constantly have to modify if their base path should have the prefix added or not, and unnecessarily restricts the consumer of the library. This behavior can be improved by only prefixing the input value if it is not prefixed already.Typically, most URI routing path parts are standardized around that format (ex: "/api/vi"). I realize that the
api_gateway_base_pathparameter was designed to use with "stages" in AWS API Gateway, but there are a ton of other proxy implementations that could utilize that field. Having the field "just work" by allowing it to handle both values with the prefix or not would make the library much easier to use in the long term.