Instruments/sensors list method could benefit from a manufacturers_id/locations_id argument

[mngh037]

Description

Currently, to filter instruments by manufacturers_id we're calling client.manufacturers.instruments(manufacturers_id=4).

Feature suggestion

Even the same thing is achieved, this suggestion to add manufacturers_id as an argument to Instruments resource list() method will make it easier to use the SDK as this is the pattern commonly used for other resources (hence users could naturally apply the same logic). Performance and redundancy could be potential pushback to implementing this feature, however.

This means that we could then filter instruments by manufacturers_id by calling client.instruments.list(manufacturers_id=4)

The same could be done for the sensors resource, where users could potentially filter sensors by locations_id like so: client.sensors.list(locations_id=42)

[russbiggs]

Since the following URLs are not currently supported:

/v3/instruments?manufacturers_id=4

/v3/sensors?locations_id=42

we wont support these in the Python SDK until they exist in the API. The latter is unlikely to ever be supported because we do not, and likely wont ever, have a resource to list sensors. Main reason being the base API call would return all sensors, i.e. /v3/sensors and there is little use for viewing all sensors. Sensor will likely always remain only as a child resource of locations i.e. /v3/locations/:id/sensors and the single resource version /v3/sensors/:id

Lets open an issue in the API for a request for the /v3/instruments?manufacturers_id=4 and develop from there. If we choose to support it we can add support into the SDK in future versions.