Best practices for supporting different versions of a 3rd-party web service


I’ve created a PowerShell module for working with F5’s LTM (local traffic management) devices via querying and manipulating the REST web service endpoints they include. F5 has made some breaking changes between versions, specifically in regards to the JSON structure of the stats data the web service returns. I want to support both versions, so I need to request and parse the data differently based on version.

I believe my preference would be to continue with a single module which loads the public functions that support both versions from a common location, but also to allow for the loading of version-specific functions based on a configuration setting in the module. Currently my module only requires PS3, so ideally I’d like to limit my solution to this version, but if there is something specific to v4 that would help in this case, I’m open to considering upping the requirement.

All feedback would be appreciated.


I’d suggest moving as much functionality as you can into private functions in a module. That way, your public functions can use whichever of those is appropriate. If your public functions can’t self-determine the needed version, then set up a module-level preference variable that’s exported from the module. That way, you’ve got an easy-to-change default for your module to “key” on when deciding which private version-specific functions to use.

Thanks for the reply, Don. Is your thinking with moving what can be moved to private functions to stop individuals from directly calling code for a different LTM version than they’re using?

So in this scenario, I’d set a custom variable in the .PSD1 under PrivateData | PSData, give it a default value, and provide instructions on how to override it for different versions. Based on the value, the public function would call the appropriate private function version. Is that the thinking? Thanks.

Private functions let you abstract the version differences. You could have MyFunctionv2 and MyFunctionv3 - note nonstandard naming convention - which get called by Do-Whatever (which is public).

And no… in the module .PSM1, just define $MyF5VersionPreference=2, for example. Exporting the variable (Export-Member) makes it visible in the global scope, so someone could change it to 3, for example. The variable isn’t “private;” you very much want it to be public. Like $ErrorActionPreference.

Do-Whatever (public function) implements the logic so that if the variable is 2, it calls MyFunctionv2; if the variable is 3, it called MyFunctionv3. And so on.

Understood - thanks!