Facebook uses oAuth 2.0, which is much easier to implement than oAuth 1.0 (which twitter uses).
An example request to verify_credentials API could look like this:
https://api.twitter.com/1/account/verify_credentials.json?oauth_consumer_key=XXX&oauth_nonce=XXX&oauth_signature_method=HMAC-SHA1&oauth_token=XXX&oauth_timestamp=123456789&oauth_version=1.0&oauth_signature=YYY
- oauth_consumer_key is self explanatory
- oauth_nonce can be pretty much a random string of characters
- oauth_signature_method is always HMAC-SHA1
- oauth_token is your access token
- oauth_timestamp is current UNIX timestamp (in UTC)
- oauth_version is always 1.0
- oauth_signature is your generated signature (which twitter will verify by reproducing)
You generate the value of the oauth_signature parameter by constructing a signature base string which consists of the following parts.
- HTTP method in upper case (in this case
GET
)
- an ampersand
&
- URL-encoded base URI (everything from
https
up to and including verify_credentials.json)
- an ampersand
&
- all request parameters in alphabetical order, url encoded. (oauth_signature should NOT be included in this though)
The pseudo code in the section Signing requests in Twitters documentation describes the signing process elegantly:
httpMethod + "&" +
url_encode( base_uri ) + "&" +
sorted_query_params.each { | k, v |
url_encode ( k ) + "%3D" +
url_encode ( v )
}.join("%26")
And then you sign the resulting base string using the consumer secret, and the access token secret. That's all there is too it :)
But before issuing any requests to the API you will of course need to actually get an access token. Once you grasp the oAuth 1.0 flow, and the signing process. You'll be home. Twitter's documentation does a great job at explaining the process, but it is a quite a bit to wrap your head around. Worth it though.