1Net::Twitter::Manual::MUisgerratCionngtTroiVb1u_t1e(d3N)Peetr:l:TDwoictutmeern:t:aMtainounal::MigratingToV1_1(3)
2
3
4

NAME

6       Net::Twitter::Manual::MigratingToV1_1 - Migrating from Twitter API v1
7       to v1.1
8

VERSION

10       version 4.01043
11

SYNOPSIS

13           use Net::Twitter
14
15           my $nt = Net::Twitter->new(
16               traits              => [qw/API::RESTv1_1/],
17               consumer_key        => $consumer_key,
18               consumer_secret     => $consumer_secret,
19               access_token        => $access_token,
20               access_token_secret => $access_token_secret,
21           );
22

DESCRIPTION

24       Net::Twitter prior to version 4.0 used Twitter API version 1. Twitter
25       API v1.1 introduced changes that are not entirely backwards compatible,
26       requiring some changes to calling code.
27
28       Net::Twitter attempts to provided backwards compatibility where
29       possible. This document describes the changes required to your existing
30       application code, using Net::Twitter, for use with Twitter's API v1.1.
31

FIRST

33   Include the API::RESTv1_1 trait
34       Wherever you create a Net::Twitter object by calling "new", replace
35       trait "API::REST" with "API::RESTv1_1". For most applications, that's
36       all that is required.
37

EXCEPTIONS

39       Trait RateLimit incompatible with API::RESTv1_1
40           The "RateLimit" trait is incompatible with Twitter API v1.1. Rate
41           limiting is one of the most extensive changes in v1.1. In v1 there
42           were two hourly rate limits, one per IP address for unauthenticated
43           calls, and one per-user/application for authenticated calls. In
44           v1.1, all calls must be authenticated, and each API endpoint (i.e.,
45           each method) has it's own rate limit. Rather than hourly, the new
46           rate limits operate on a 15 minute window.
47
48           If your code currently uses the "RateLimit" role, you'll need to
49           write some custom code provide equivalent functionality.
50
51       rate_limit_status
52           The return value for "rate_limit_status" is entirely different. See
53           Twitter's API rate_limit_status
54           <https://dev.twitter.com/docs/api/1.1/get/application/rate_limit_status>
55           documentation for details.
56
57       blocking
58       blocking_ids
59       friends
60       followers
61           With API v1.1, these methods use cursor based paging. If you do not
62           pass a "cursor" parameter, Twitter assumes "cursor => -1">.
63           Existing code that expects an arrayref return value must be
64           modified to expect a hashref and dereference the "users" slot:
65
66               # With API v1
67               my $r = $nt->friends;
68               my @friends = @$r;
69
70               # With API v1.1
71               my $r = $nt->friends;
72               my @friends = @{$r->{users}};
73
74       search
75           The "search" method semantics and return value are substantially
76           different between Twitter API v1 and v1.1. In v1, "search" was
77           provided by the "API::Search" trait. In v1.1, "search" is included
78           in the "API::RESTv1_1" trait.
79
80           So, first, drop "API::Search" from your calls to "new". The
81           "API::Search" trait is incompatible with "API::RESTv1_1".
82
83           In v1, Twitter returned a hashref with several keys containing meta
84           data. The actual array of results were contained in the "results"
85           slot:
86
87               # With Twitter API v1
88               my $nt = Net::Twitter->new(traits => [qw/API::REST API::Search/]);
89
90               my $r = $nt->search('perl hacker');
91               for my $status ( @{$r->{results} ) {
92                   # process each status...
93               }
94
95           In v1.1, Twitter returns a hash with 2 slots: "search_metadata" and
96           "statuses".
97
98               # With Twitter API v1.1
99               my $nt = Net::Twitter->new(traits => [qw/API::RESTv1_1/], %oauth_credentials);
100
101               my $r = $nt->search('perl hacker');
102               for my $status ( @{$r->{statuses} ) {
103                   # process each status...
104               }
105
106           Paging through search results works differently in v1.1. In v1,
107           Twitter offered a "page" parameter:
108
109               # With Twitter API v1
110               for ( my $page = 1; $page <= 10; ++$page ) {
111                   my $r = $nt->search({ q => $query, page => $page, rpp => 100 });
112                   last unless @{$r->{results}};
113
114                   # process a page of results...
115               }
116
117           In v1.1, use "max_id" and "count" to get paged results:
118
119               # With Twitter API v1.1
120               for ( my %args = ( q => $query, count => 100 ), my $n = 0; $n < 1000; ) {
121                   my $r = $nt->search({ %args });
122                   last unless @{$r->{statuses}};
123
124                   $args{max_id} = $r->{statuses}[-1]{id} - 1;
125                   $n += @{$r->{statuses}};
126
127                   # process a page of results...
128               }
129
130   DEPRECATED METHODS
131       Some Twitter API v1 methods are not available in v1.1:
132
133       friends_timeline
134           Use "home_timeline" instead.
135
136       friendship_exists
137       relationship_exists
138       follows
139           "friendship_exists" and it's aliases are not supported in API v1.1.
140           Use "show_friendship" instead:
141
142               my $r = $nt->show_relationship({
143                   source_screen_name => $user_a,
144                   target_screen_name => $user_b,
145               });
146               if ( $r->{relationship}{source}{following} ) {
147                   # $user_a follows $user_b
148               }
149
150
151
152perl v5.36.0                      2022-N0e7t-:2:2Twitter::Manual::MigratingToV1_1(3)
Impressum