Currently API methods accept string values and are themselves responsible for parsing those values into a data structure and validating those values. Many API methods use common inputs though, for example, a list of site IDs or a list of dates. At the moment this results in code redundancy and often times code that isn't fully tested.

We can solve this for 3.0 by introducing a feature that is available in many MVC frameworks (including, eg Spring: http://stackoverflow.com/questions/16942193/spring-mvc-complex-object-as-get-requestparam). In core/API/Proxy.php, we can detect the type hints of API methods, construct those types w/ the query parameter values and pass them to the API methods, thus moving the responsibility of parsing & validating to Piwik's middleware.

For example, an API method that might've looked like this before:

public function doSomething($sites, $dates)
{
    $sites = explode(',', $sites);
    $sites = array_map('intval', $sites);
    Piwik::checkUserHasAdminAccess($sites);

    $dates = explode(',', $dates);
    $dates = array_map('\Piwik\Date::factory', $dates);

    // ...
}

would instead look like:

public function doSomething(SitesList $sites, DatesList $dates)
{
    Piwik::checkUserHasAdminAccess($sites->getIdSites());

    // ...
}

Should increase code reuse, increase code testability, and well, gosh darnit, just look better.

A related possibility, is allowing results to be complex types as well, but this isn't quite as important to Piwik since most of the time the result is a DataTable.