TODO

# new stuff

* http://dev.bitly.com/links.html#v3_user_save_custom_domain_keyword
* http://dev.bitly.com/link_metrics.html#v3_link_encoders
* http://dev.bitly.com/link_metrics.html#v3_link_encoders_by_count
* http://dev.bitly.com/link_metrics.html#v3_link_referrers_by_domain
* http://dev.bitly.com/user_metrics.html#v3_user_popular_earned_by_clicks
* http://dev.bitly.com/user_metrics.html#v3_user_popular_earned_by_shortens
* http://dev.bitly.com/user_metrics.html#v3_user_popular_owned_by_clicks
* http://dev.bitly.com/user_metrics.html#v3_user_popular_owned_by_shortens
* ... more?

# old todos

* Expand: Eliminate duplicate parameters
* Expand: Throw exception when exceeding max of 15 hash/shortUrls
* Expand: Throw exception when not at least 1 hash/shortUrls
* ALL: check required parameters are present before making the call?
* ALL: verify rollup behaviour
* ALL: verify day parameter, not all metrics request have it
* UserNetworkHistory: split expanded and collapsed user into 2 structures? same as expand/rollup?
* Calls that take no parameters like UserTrackingDomainList could be executed right away. Downside: 2 behaviours in the BitlyClient class.
* have another look at the response model - should each and every name be unique? could collapse a bunch of expanded/rolledup integration tests and would eliminate the need for using XYZ.ABC types in the code, everything could be done in the imports
* UserReferrersExpanded: if the unit parameter is missing, this call returns an entirely different response, and rollup has no influence
* UserCountriesRolledUpRequest is broken, the response is always expanded
* MetricsRequest: not all requests that inherit from MetricsRequest accept a "link" parameter