Client versus HubInstance Comparison

A comparison of the new Client class versus the legacy HubInstance class.

Topic	Client	HubInstance
History	Designed from the ground up in 2020-21 to provide a more solid foundation for long-running scripts	Developed organically since 2018
Files	Client.py, Authentication.py	HubRestApi.py and all the other blackduck/*.py files
Backwards Compatibility	Client is not backwards compatible with HubInstance	Yes
requests.session	Uses a single underlying session. Connection pooling provides a significant performance benefit.	No session used, new connection established every request
requests	Encourages direct access to the underlying Requests library's session.get(), put(), post(), and delete() methods and passes along named parameters via **kwargs.	Requires custom execute_get(), execute_put(), execute_post() and execute_delete() methods that do not allow **kwargs.
timeout	Supported	Not supported
retries	Supported	Not supported
proxies	Supported	Not supported
TLS certificate verification	Set once, persisted	Same
Bearer token	Automatically renewed before expiry	Expires after two hours; must re-instantiate HubInstance to renew
Base URL	Set once and automatically prepended to every request	User must include with every request
.restconfig.json	Not supported; user to implement if desired	Supported
Endpoint methods	No endpoint specific methods are provided. Instead Client defines a core set of methods that generically apply across the entire REST API. See the Client API Reference.	Over 150 methods for many endpoints e.g. get_projects(), create_project(), get_project_versions(), ... at least 70% of these methods are for basic CRUD (create, read, update, and delete) operations
Resources	Discover and traverse _meta/links with list_resources() and get_resource()	User to manually traverse
Pagination	Consistently supported with get_resource(name, items=True) and get_items(url, page_size=100) and backed by a generator to progressively fetch	User to implement
Media type headers	Defaults headers provided {'accept': "application/json", 'content-type': "application/json"}, user to override	Defaults provided, with many 'accept' / 'content-type' headers hard-coded for specific endpoint methods
Error handling	get_json(url) consistently checks for HTTPErrors and JSONDecodeErrors	Depends on specific endpoint method