Traits

• ApiMethods
• AppAuth
• DecodeHtmlEntities
• NormalizeBooleans
• RetryOnError
• Enchilada

ApiMethods is a direct replacement for Net::Twitter's API::RESTv1_1 trait.

Net::Twitter's InflateObjects trait will be released as a separate distribution to minimize Twitter::API's dependencies.

If you are using the Net::Twitter's WrapResults trait, Twitter::API provides a better way to access the what it provides. In list context, API calls return both the API call results and a Twitter::API::Context object that provides the same accessors and attributes WrapResult provided, including the result accessor.

So, if you had:

    my $r = $client->home_timeline;
    $r->result;
    $r->rate_limit_remaining;

You can change that to:

    my ( $result, $context ) = $client->home_timeline;
    $result;
    $context->rate_limit_remaining;

Or for the smallest change to your code:

    my ( undef, $r ) = $client->home_timeline;
    $r->result; i            # same as before
    $r->rate_limit_remaning; # same as before

However, there is migration support for WrapResult. Call the constructor with option "wrap_result => 1" and Twitter::API will return the context object, only, for API calls. This should give you the same behavior you had with WrapResult while you modify your code. Twitter::API will warn when this option is used. You may disale warnings with "$ENV{TWITTER_API_NO_MIGRATION_WARNINGS} = 1".

If you are using any other Net::Twitter traits, please contact the author of Twitter::API. Additional traits may be added to Twitter::API or released as separate distributions.

If you are using "decode_html_entities => 1" in Net::Twitter, drop that option and add trait DecodeHtmlEntities. Traits AppAuth and RetryOnError provide the same functionality in Twitter::API as their Net::Twitter counterparts. So, no changes required, there, if you're using them. (Although there is a change to one of AppAuth's methods. See the "OAuth changes" discussion.)

NormalizeBooleans is something you'll probably want. See the NormalizeBooleans documentation.

Enchilda just bundles ApiMethods, NormalizeBooleans, RetryOnError, and DecodeHtmlEntities.

Other constructor options

If you are setting useragent_lass and/or useragent_args to customize the user agent, just construct your own pass it to new with "user_agent => $custom_user_agent".

If you are using ua to set a custom user agent, the attribute name has changed to usre_agent. So, pass it to new with "user_agent => $custom_user_agent".

By default, Twitter::API uses HTTP::Thin as its user agent. You should be able to use any user agent you like, as long as it has a request method that takes an HTTP::Request and returns an HTTP::Response.

If you used clientname, clientver, clienturl, or useragent, see "agent" in Twitter::API and "default_headers" in Twitter::API. If all you're after is a custom User-Agent header, just pass "agent => $user_agent_string". It will be used for both User-Agent header and the X-Twitter-Client header on requests. If you want to include your own application version and url, pass "default_headers => \%my_request_headers".

OAuth changes

The following methods exist only for migration from Net::Twitter and will be removed in a future release. A warning is issued on each call to these methods. To disable the warnings, set "$ENV{TWITTER_API_NO_MIGRATION_WARNINGS} = 1".

• get_authentication_url

  replace with oauth_authentication_url or oauth_request_token and oauth_authentication_url

• get_authorization_url

  replace with oauth_authorization_url or oauth_request_token and oauth_authorization_url

• get_access_token

  replace with oauth_access_token

If you are using the AppAuth trait, replace request_access_token calls with oauth2_token calls. Method oauth2_token does not set the "access_token" attribute. Method "request_access_token" is provided for transitional support, only. It warns like the OAuth methods discussed above, and it sets the "access_token" attribute so existing code should work as expected during migration. It will be removed in a future release.