Making a Twitter API Request

But what goes in our request? If we take a look at the Twitter REST API 1.1 at https://dev.twitter.com/docs/api/1.1, we’ll find the call statuses/home_timeline, which is called via an HTTP GET, and which returns “a collection of the most recent Tweets and retweets posted by the authenticating user and the users they follow.” Not shown on this page, but fundamental to Twitter API calls, is the fact that we can append .json to get JSON-formatted results, or .xml to get XML. Foundation’s JSON parser is far easier to use than its XML parser, so our URL will be https://api.twitter.com/1.1/statuses/home_timeline.json. Since both Twitter and iOS 9 really want us to use SSL (in fact, it’s a requirement for the Twitter API), our URLs will always start with https://.

So now we need to create an SLRequest. The docs show us a single convenience initializer, which takes a service type, request method, URL, and a dictionary of parameters. We already know how to fill in these four parameters:

• serviceType: The constant SLServiceTypeTwitter.

• requestMethod: The Twitter docs say we need an HTTP GET; for this, the Social framework provides the constant SLRequestMethodGET.

• url: We already figured this out as https://api.twitter.com/1.1/statuses/home_timeline.json.

• parameters: This is a dictionary of name-value pairs. The Twitter docs tell us we need to provide the screen_name or user_id parameters, so that’s what will go in our dictionary.

Now we can go back into reloadTweets and finish it up. To do so, we’ll build up a call to performRequestWithHandler, and have the handler block just call the handleTwitterData method we stubbed out. Continuing from after we did the guard to make sure twitterAccounts has at least one member, this goes right before the }) that ends the existing closure.

There’s a lot going on here! Let’s take it slowly.

• Lines 1--3 set up a dictionary of parameters to provide to the request. The available parameters depend on the web service’s API. Twitter lets us send a count of how many tweets to return (the default is 20), so let’s make things interesting and fetch 100.

• Lines 4--5 convert a String representation of the Twitter web service URL into an NSURL, the type needed by the SLRequest initializer.

• Lines 6--9 creates the SLRequest with the URL and parameters we’ve set up, along with the constant for the Twitter service type, and the SLRequestMethod enumeration value for GET requests.

• Line 10 gets the first object from the twitterAccounts array, and assigns it to the request’s account property. Since the SLRequest wants an object of type ACAccount, and the array turns out to be of type AnyObject, we forcibly convert the value to the correct type with as! ACAccount.

• Lines 11--15 finally performs our request. It takes a closure as its parameter, which is executed once the request finishes. We saw before that this closure is of type SLRequestHandler, which means it receives an NSData, NSHTTPURLResponse, and NSError as parameters. Inside the closure, we just pass these parameters to the stub handleTwitterData method we wrote earlier; we can build that out later.

  Notice that by writing a closure within the closure we were already inside of, when we’re done, we will have two consecutive lines of }), the telltale end-of-closure syntax.

We’ve written a lot of code—and with closures two levels deep, this might be the hardest thing in the whole book so far—so let’s run it to make sure it at least builds and starts up in the Simulator. Nothing interesting will happen in the Simulator, but the call from viewDidLoad to reloadTweets should produce a message like the following in the Debug area at the bottom of the Xcode window:

This means the request is being sent to Twitter’s web service and being responded to. Now it’s up to us to act on that response.