As pyTenable starts to near it’s 3rd birthday, I’ve started working on a complete rewrite of the codebase. For a number of reasons, the current v1 code has become a monstrosity of tests, repeated code, and assumptions in the APIs that are no longer correct. Thats not to say that it doesn’t work, or even work well for what folks are using it for, just that code maintainability has been a concern as of late. My hope is that with this v2 codebase, that some of the issues can be ironed out, and that the test suite can be brought under control (1500+ tests as of writing!!).
To start, I’m removing all of the base connection logic from the library and instead relying on the work I have been doing on the RESTfly library. Over the last year RESTfly has become my goto library to use when writing wrappers for APIs, and there is no reason to exclude the library that started this journey. As RESTfly takes into account all of the lessons learned from pyTenable, and then extends them, the overall amount of connection code is now quite minimal (from 346 lines to 106 lines).
Also by leveraging some of the newer capabilities in RESTfly, the APIEndpoint classes themselves become quite reusable, as they take advantage of the newer private verb methods within RESTfly. This would mean that even simple calls can be condensed to a single line.
For the purpose of validating the inputs provided by the caller, we will be shying away from the olf check function and instead leverage the awesome Marshmallow library. While our use-case is a bit opposite of the traditional use-case that Marshmallow is used for, with minimal tinkering I’ve been able to use it with some significant successes. For example, the annoyingly complicated filter validation and transformation code code (which as I had to bolt onto it, regretted writing this way) has instead been properly broken down into the different filter formats.
Lastly as the Tenable.io API grew over time, the structure of the Tenable.io package within the library proved to be quite constraining. The new library will properly break down the APIs into the apps within the platform. This should also solve for some of the method overloading that currently has to happen.
The end result of all of this is that even on a simpler API (such as access-groups), the overall number of lines that need to be written (including the doc-strings) went from 363 lines to 288 lines.
The v2 codebase is being written in a bare branch within the pyTenable repository. If you’re interested in monitoring its progress, by all means take a gander at the work being done.