In this text I am going to describe a very straightforward way of how to make use of Twitter’s REST API v1.1. I put some code together for that purpose, so that requesting data just needs the API URL, the API parameters and a vector containing the OAuth parameters.

Before you can get started you have to login to your Twitter account on dev.twitter.com, create an application and generate an “Access Token” for it. So let’s jump right in and fetch IDs of 10 followers of @hrw (Human Rights Watch). The necessary code is located on GitHub – download all three files and then you can just edit the example below as suggested.

setwd("/[...]/RTwitterAPI/");
source("./twitter_api_call.R");

params <- c(
  "oauth_consumer_key"     = "[API Key]", 
  "oauth_nonce"            = NA,
  "oauth_signature_method" = "HMAC-SHA1",
  "oauth_timestamp"        = NA,
  "oauth_token"            = "[Access Token]",
  "oauth_version"          = "1.0",
  "consumer_secret"        = "[API Secret]",
  "oauth_token_secret"     = "[Access Token Secret]"
);

url   <- "https://api.twitter.com/1.1/friends/ids.json";
query <- c(cursor=-1, screen_name="hrw", count=10);

result <- twitter_api_call(url, query, params, print_result=TRUE)

The result is a JSON containing the IDs of 10 followers (and it looks so pretty thanks to jsonlite::prettify()):

{
	"ids" : [
		248801839,
		16635362,
		2208011520,
		177801089,
		307257945,
		273460384,
		17019963,
		247963674,
		1182834140,
		33095424
	],
	"next_cursor" : 1470449820154332575,
	"next_cursor_str" : "1470449820154332575",
	"previous_cursor" : 0,
	"previous_cursor_str" : "0"
}

OAuth Version 1

Twitter provides access to its service via a REST API whose current version is 1.1. Authorization is realized through OAuth version 1.0a. Due to that, handling the API is less trivial than just appending your password to the request – but also considerably more secure. Opposed to standard password-based authentication – OAuth distinguishes between the server (Twitter), the third-party client (the program calling the API) and the resource owner (the owner of the API account) by specifying an authentication flow where the resource owner grants access to the third-party client by programmatically providing a secret token in the end. But as in this case the third-party client and the resource owner are effectively identical the process simplifies to just manually creating an access token and its corresponding “token secret” and then using those directly within the script. Referring to the OAuth 1 authentication flow chart – we can skip steps A to F and focus on entirely on G.

Signing the Request for OAuth1

The authorization of a request itself happens by glueing together a string which contains all the details about that request – URL, query parameters, OAuth keys and values – and then signing this so called “signature base string” with the two secret tokens –

oauth_token_secret

 and

consumer_secret

 applying an algorithm referred to as HMAC-SHA1. HMAC-SHA1 is provided by the digest package. What you get in the end after some more processing is the

oauth_signature

 which is sent along with the request and verified by the server. The creation of that signature is implemented in RTwitterAPI/oauth1_signature.R - a detailed description may be found here.

Structure of the GET Request

The GET request which is finally sent via RCurl needs a propperly set up header containing an “Authentication” section providing all the various

oauth_*

 settings. This part is implemented in RTwitterAPI/twitter_api_call.R. The meaning of the

oauth_*

  key/values, as well as the composition of the header is described here.

---

(original article published on www.joyofdata.de)