Facebook usa oAuth 2.0, que es mucho más fácil de implementar que oAuth 1.0 (que usa Twitter).
Un ejemplo de solicitud de verify_credentials API podría tener este aspecto:
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 se explica por sí
- oauth_nonce puede ser más o menos una cadena aleatoria de caracteres
- oauth_signature_method es siempre HMAC -SHA1
- oauth_token es su token de acceso
- oauth_timestamp es el valor timestamp UNIX (en UTC)
- oauth_version es siempre 1.0
- oauth_signature es su firma generada (que Twitter verificará mediante la reproducción)
generar el valor del parámetro oauth_signature mediante la construcción una cadena base de firma que consta de las siguientes partes. método
- HTTP en mayúsculas (en este caso
GET)
- un ampersand
&
- de base codificada en URL URI (todo de
https hasta e incluyendo verify_credentials.json)
- un ampersand
&
- todos los parámetros de solicitud en orden alfabético, codificados en url. (Oauth_signature no deben ser incluidos en esto, sin embargo)
El pseudo código en la sección Signing requests in Twitters documentation describe el proceso de firma con elegancia:
httpMethod + "&" +
url_encode( base_uri) + "&" +
sorted_query_params.each { | k, v |
url_encode (k) + "%3D" +
url_encode (v)
}.join("%26")
Y después de firmar la secuencia de bases resultante usando el secreto de los consumidores, y el token secreto de acceso Eso es todo lo que hay :)
Pero antes de emitir cualquier solicitud a la API, por supuesto necesitarás obtener un token de acceso. Una vez que capte el flujo de oAuth 1.0 y el proceso de firma. Estarás en casa. La documentación de Twitter hace un gran trabajo al explicar el proceso, pero es un poco difícil de entender. Vale la pena sin embargo.