Currently, all API interactions are handled by the same client instance. In the interest of simplicity, it is worth exploring whether their functionality could be split or at least moved to different definitions (this would also allow making the websocket endpoint an optional dependency).
In the latter case, the EventClient would subclass the regular Client class to extend it with websocket-specific functionality.
I cannot think of a plausible use-case in which the event stream would be required on its own, without any need for REST API access.
Currently, all API interactions are handled by the same client instance. In the interest of simplicity, it is worth exploring whether their functionality could be split or at least moved to different definitions (this would also allow making the websocket endpoint an optional dependency).
In the latter case, the
EventClientwould subclass the regularClientclass to extend it with websocket-specific functionality.I cannot think of a plausible use-case in which the event stream would be required on its own, without any need for REST API access.