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

This topic contains 4 replies, has 2 voices, and was last updated by Profile photo of Joel Newton Joel Newton 1 week, 6 days ago.

  • Author
    Posts
  • #68788
    Profile photo of Joel Newton
    Joel Newton
    Participant

    Hi,

    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.

    Cheers,
    Joel

  • #68790
    Profile photo of Don Jones
    Don Jones
    Keymaster

    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.

    • #68796
      Profile photo of Joel Newton
      Joel Newton
      Participant

      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.

  • #68799
    Profile photo of Don Jones
    Don Jones
    Keymaster

    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.

You must be logged in to reply to this topic.