I've never been a fan of how this (and some of our other libraries) determine what endpoint to hit in our API by basically taking the name of the class, figuring out how to make it plural and then lowercasing it. The "class URL" and "instance URL" utility functions are clunky, do unnecessary reflection, are hard to follow, and are simply begging to break one day in the future simply because a class name does not one-to-one match an endpoint on the API.
Instead, as was done in the C# library during its rewrite last year, this "automagical" utility was removed and instead replaced with explicit endpoint strings. This not only returns transparency to what endpoint is being hit on each function, but also dramatically improves readability of our code.
This PR also makes minor tweaks to how the requestor function operates under-the-hood, mainly by containing client API base and version information solely to that class. Previously, the whole URL (including base and API version) were determined in each service. Now, that calculation is pushed downstream into one location inside the actual request function. This restructuring also allows for the introduction of API version override on a per-request basis, making "beta" endpoints more obvious and meaning less changes needed when a beta features migrates to general availability and no longer needs to hit the "beta" API version.
Remove endpoint determination by class, replace with explicit endpoint strings
Modify Requestor under-the-hood to handle new endpoint strings
Add support for overriding API version on a per-request basis using new endpoint strings
Testing
All unit tests pass with no re-recording necessary, implying that the change does not introduce a breaking change to the end-user.
Modifications were needed to the mocking rules for Billing unit tests to account for the changes made to the request function downstream. This did not affect the actual functionality or assertions of those unit tests.
Pull Request Type
Please select the option(s) that are relevant to this PR.
[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[x] Improvement (fixing a typo, updating readme, renaming a variable name, etc)
Description
I've never been a fan of how this (and some of our other libraries) determine what endpoint to hit in our API by basically taking the name of the class, figuring out how to make it plural and then lowercasing it. The "class URL" and "instance URL" utility functions are clunky, do unnecessary reflection, are hard to follow, and are simply begging to break one day in the future simply because a class name does not one-to-one match an endpoint on the API.
Instead, as was done in the C# library during its rewrite last year, this "automagical" utility was removed and instead replaced with explicit endpoint strings. This not only returns transparency to what endpoint is being hit on each function, but also dramatically improves readability of our code.
This PR also makes minor tweaks to how the requestor function operates under-the-hood, mainly by containing client API base and version information solely to that class. Previously, the whole URL (including base and API version) were determined in each service. Now, that calculation is pushed downstream into one location inside the actual request function. This restructuring also allows for the introduction of API version override on a per-request basis, making "beta" endpoints more obvious and meaning less changes needed when a beta features migrates to general availability and no longer needs to hit the "beta" API version.
Testing
Pull Request Type
Please select the option(s) that are relevant to this PR.