Desenvolvimento de Aplicaes Sociais a partir de APIs em Redes Sociais Online

O. C. Xavier
Technical Report July RT-INF_000-10 2010 Relatrio Tcnico

Julho

The contents of this document are the sole responsibility of the authors. O contedo do presente documento de nica responsabilidade dos autores.

Instituto de Informtica Universidade Federal de Gois

www.inf.ufg.br

Desenvolvimento de Aplicaes Sociais A Partir de APIs em Redes Sociais Online

Otvio C. Xavier
otaviocx@gmail.com

Cedric L. de Carvalho
cedric@inf.ufg.br

Resumo. Redes Sociais Online so sistemas Web para relacionamento e troca de conhecimentos entre pessoas. Um dos frutos da Web 2.0, as redes sociais podem ser de propsito geral ou para um pblico especco (msicos, mdicos, pessoas solteiras, etc.). Com a popularidade, as redes sociais online foram ganhando mais funcionalidades, tornando a interatividade entre os usurios cada vez maior. Atualmente, muitas redes sociais online possuem APIs para que os prprios usurios possam criar aplicaes para elas. Este trabalho destina-se ao estudo das APIs das redes sociais mais populares (como Facebook, Twitter, Orkut, Linkedin, Flickr e MySpaces). Tais APIs sero descritas com exemplos de implementaes. Tambm sero vistas tecnologias como OpenSocial, OAuth e OpenID, que auxiliam no desenvolvimento de aplicaes para redes sociais. Palavras-Chave: Redes Sociais Online, API, Facebook, Twitter, Flickr, OpenSocial, OpenID, OAuth.

Introduo

Desde sua origem, as redes sociais online (tambm chamadas de sites de rede social) tm atrado milhes de usurios em todo o mundo. Muitos destes integraram tais sites em suas rotinas dirias. Atualmente existem centenas de redes sociais online, com vrias implementaes tecnolgicas diferentes, dando apoio uma grande quantidade de prticas e interesses. Algumas redes sociais caracterizam-se por serem um canal de comunicao de sites pr-existentes. Outras ajudam estranhos a se conhecerem, baseadas nos interesses em comum das pessoas. Existem redes sociais online de mbito geral, mas tambm aquelas destinadas pessoas de um pas, raa, lngua, religio ou interesses especcos [3]. Os sites de rede social so baseados nos relacionamentos reais entre pessoas. Com isso, muitos destes sites destinam-se formao de redes online entre pessoas que j se conhecem pessoalmente. A rede de cada usurio conecta-se com redes de outros usurios formando uma grande rede em cada um dos sites de rede social. Essas grandes redes podem ser usadas como plataformas para aplicaes sociais. Tais aplicaes necessitam do colaborativismo e do relacionamento entre as pessoas, presentes em redes sociais. Visando explorar essa possibilidade,

Mestrando em Cincia da Computao, INF-UFG Orientador

Redes Sociais e APIs

alguns sites de rede social desenvolveram APIs1 , permitindo que os prprios usurios faam aplicaes sociais. Este trabalho destina-se a descrever, testar e implementar aplicaes atravs das APIs de redes sociais online mais comuns (como o Facebook [14], Twitter [22], LinkedIn [28], Flickr [27] e OpenSocial [5]). Tambm ser visto o OpenID [30], um arcabouo para autenticao nica de usurios em vrias aplicaes e o OAuth [18], um protocolo para autorizao segura de aplicaes para acesso a dados de outras aplicaes. A principal motivao para tal estudo est na possibilidade de desenvolvimento de aplicaes sociais que interconectem os usurios de redes sociais online distintas. Outro fator motivante para este trabalho est associado Web Semntica. Atualmente, so poucos os sites de rede social que tratam semanticamente as informaes e relacionamentos entre seus membros.

Redes Sociais Online

Sites de redes sociais podem ser denidos como servios, baseados na web, que permitem aos seus usurios [3]: 1. Construir um perl pblico ou semi-pblico em um sistema delimitado; 2. Elaborar uma lista de amigos com quem eles compartilham uma conexo e 3. Ver e navegar pela sua lista de conexes e pelas de outras pessoas. A natureza e a nomenclatura dessas conexes podem variar de acordo com o site. Apesar de os sites de rede social atuais implementarem uma srie de funcionalidades, sua espinha dorsal consiste em perl pblico para cada usurio que mostra seus dados e a lista de conexes dele [3]. Aps cadastrar-se em um site de rede social, exibido um formulrio ao usurio, com perguntas sobre ele. O perl formado a partir das respostas do usurio que podem incluir idade, localizao, interesses, uma foto e um texto auto-descritivo do usurio. Depois que o usurio cria seu perl, o prximo passo em um site de rede social identicar os usurios j cadastrados que ele deseja ter como conexes. As nomenclaturas mais comuns para as conexes so "Amigos", "Contatos", "Fs"ou "Seguidores". Tais conexes podem ser bidirecionais ou unidirecionais. Conexes bidirecionais requerem que os dois indivduos a aceitem, j as unidirecionais no. As nomenclaturas mais comuns para as conexes unidirecionais so "Seguidores"e "Fs". comum os sites de rede social possurem tambm lbum de fotos e uma rea em que os usurios podem se comunicar atravs de mensagens de texto [3]. Como os sites de rede social incentivam os usurios a colocarem dados pessoais e ntimos, pessoas mal intencionadas podem usar tais dados para violar a segurana dos usurios. Para aliviar esse problema, alguns sites de rede social adotaram nveis de privacidade. Os usurios tm a opo de escolher, por exemplo, que apenas seus contatos vejam seus dados pessoais.

2.1

Histrico

De acordo com a denio acima, o primeiro site de rede social surgiu em 1997. O SixDegrees.com permitia que seus usurios cadastrassem pers e montassem uma lista de amigos, com pers de outros usurios. A partir de 1998, os usurios do SixDegrees.com podiam navegar nas listas de amigos de outros usurios. Muitos sites j implementavam alguma dessas
Application Programming Interfaces descrevem interfaces com um conjunto de funcionalidades, visando o reuso delas.
1

Redes Sociais e APIs

funcionalidades antes do SixDegrees.com. Entretanto, ele foi o primeiro a combin-las [3]. O SixDegrees.com promovia-se como sendo uma ferramenta para ajudar pessoas a se conectarem e enviar mensagens para outras. Enquanto ele atraia milhes de usurios, comeou a tornar-se um negcio invivel. Em 2000 o servio foi fechado [3]. De 1997 a 2001, vrias ferramentas de comunidade que combinavam pers e listas pblicas de amigos foram lanadas. Uma delas foi o LiveJournal [25], lanado em 1999. Ele permite que os usurios criem "jornais pessoais". Cada pessoa pode montar uma pgina com as notcias de seu interesse. O LiveJournal permite conexes unidirecionais. Um usurio recebe as notcias dos usurios em sua lista de conexes. Outros sites, implementaram caractersticas de rede social aps seu surgimento. A exemplo o coreano Cyworld, fundado em 1999 e que implementou funcionalidades de redes sociais em 2001 e o sueco LunarStorm, que se tornou um site de rede social em 2000 [3]. A prxima gerao de sites de rede social veio com o Ryze.com, o Fotolog e o Friendster. Ryze.com, criado em 2001, ajudava as pessoas a montar redes sociais de negcios. O Fotolog surgiu em 2002, com uma ideia semelhante a de um blog, entretanto com fotos como tema central de cada artigo. O Friendster, criado em 2002, surgiu como um complemento ao Ryze. Enquanto todos os sites sociais da poca focavam em encontros amorosos entre estranhos, o Friendster focava em amigos de amigos (friends-of-friends). Seus criadores Jonathan Abrams e Cris Emmanuel assumiram que encontros amorosos em que o casal possuia um amigo em comum, eram mais bem sucedidos [3]. Entretanto, os usurios do Friendster tambm o usavam para aumentar as suas redes de amigos mais rpido que com encontros presenciais [32]. Com seu sucesso, em apenas um ano o Friendster j possua mais de 30 milhes de usurios [3]. Contudo, tamanho sucesso acabou acarretando diculdades tcnicas, gerando uma evaso de usurios. A partir de 2003, redes sociais tornaram-se comuns em sites da Web, como pode ser visto na Figura 1. Sites como LinkedIn, Visible Path e Xing formam redes sociais prossionais. No LinkedIn, por exemplo, os usurios podem cadastrar em seu perl um currculo acadmico e prossional. Tal currculo pode ser usado por empresas na seleo de prossionais. No Couchsurng os usurios compartilham hospedagens. Um usurio pode oferecer hospedagem outro usurio que deseja viajar para a sua cidade. O MyChurch conecta igrejas crists e seus membros. Alguns sites usam os conceitos de redes sociais online para compartilhamento de contedo multimdia. A exemplo, o Flickr para compartilhamento de fotos, o YouTube para vdeos e o Last.FM para msicas [3]. O MySpace, criado em 2003, cresceu rapidamente, como sendo uma alternativa ao ento saturado Friendster. Apesar de ter sido criado com propsito similar ao do Friendster, o MySpace ganhou popularidade entre bandas de rock. At 2004, a maioria dos seus usurios eram msicos. Em 2005, ele tornou-se o maior site de rede social (em nmero de usurios e visitantes) do mundo [3]. O Orkut, criado em 2004, a rede social do Google. Desde sua criao, ganhou popularidade entre os brasileiros, tornando-se a rede social mais usada no Brasil [13]. O Facebook, criado em 2004, possua um foco diferente de seus precursores. Ele foi criado para a formao de redes em faculdades especcas. Inicialmente, estava disponvel apenas para os estudantes de Harvard. Em 2005, ele se expandiu para escolas de ensino mdio, posteriormente para prossionais e redes corporativas e atualmente para qualquer pessoa. O principal diferencial do Facebook desde sua criao, era a API que possibilitava aos usurios desenvolver suas prprias aplicaes embutidas ele [3].

Redes Sociais e APIs

Figura 1: Linha do tempo do surgimento dos principais sites de rede social at 2006. [3] Em 2006, o Twitter foi criado, gerando um novo conceito: o microblogging. Os usurios escrevem pequenas mensagens (de at 140 caracteres), sobre algo que est sentindo ou acontecendo. As conexes so unidirecionais. Apenas os usurios que esto conectados a uma pessoa, recebem as mensagens dela [23]. Com esse novo conceito, o Twitter cresceu rapidamente, tornando-se um novo meio de comunicao. Atualmente ele usado para diversos ns como publicao de notcias, sorteios, venda de produtos e reunies entre outros. Como o Facebook, o Twitter foi criado com uma vasta API para criao de aplicaes pelos prprios usurios. A partir do sucesso das APIs do Facebook e do Twitter, em 2007 o Google lanou o OpenSocial [21]. Um conjunto de APIs para criao de aplicaes Web em sites de redes sociais. Sites como Orkut, MySpace e LinkedIn so compatveis com o OpenSocial para criao de aplicaes. Para facilitar a integrao ao OpenSocial, a Apache desenvolveu o Shindig [12], um container open-source para hospedagem de aplicativos em OpenSocial.

Redes Sociais e APIs

APIs para desenvolvimento de aplicaes em sites de redes sociais

Como toda aplicao Web, sites de redes sociais so hospedados em servidores Web. Para que outras aplicaes consigam interagir com aplicaes Web, so usados Web Services. Ento, as APIs de redes sociais online so Web Services destinados a oferecer recursos e funcionalidades, presentes na rede social, para aplicaes externas. Essas APIs transformam os sites de rede social em plataformas para aplicaes sociais. Nessa seo sero descritas e exemplicadas as APIs das principais redes sociais online. As APIs Web de Redes Sociais Online so Web Services que permitem acesso e manipulao de informaes sociais. A maioria das APIs so implementadas atravs dos princpios REST[9]. REST, ou Transferncia de Estado Representacional, termo introduzido por Roy Fielding em sua tese de doutorado, descreve um estilo de arquitetura para sistemas hipermdia derivado de vrios estilos baseados em redes como a Web [9]. Nessa tcnica as mensagens trocadas so encapsuladas diretamente no protocolo HTTP. H um foco nos recursos e no nas chamadas aos procedimentos/servios, como em outras abordagens. No REST so feitas requisies para recursos e no servios. Essa abordagem pode ser interessante para aplicaes em que mais importante a interoperabilidade do que um contrato formal entre as partes [33]. Os recursos so representados por URIs e tambm podem ser chamados de mtodos, caso representem alguma ao.

3.1

OAuth

OAuth ou Open Authorization um padro aberto que permite aos usurios de um site garantirem acesso, por uma aplicao externa, aos seus recursos privados sem ter que compartilhar suas senhas e logins [18]. O foco principal do OAuth est na autorizao e no na autenticao. Sendo assim, ele prev nveis de autorizao, que o usurio pode aceitar ou no. O OAuth foi construdo baseado nos padres proprietrios Google AuthSub, Yahoo BBAuth e Flickr API Auth. Tambm pode ser caracterizado como um protocolo. Sua especicao consiste em duas partes. A primeira parte dene um processo no navegador, para redirecionamento do usurio nal para autorizao aos seus recursos, pelo cliente2 . A segunda parte dene um mtodo para realizao de requisies HTTP autenticadas usando dois conjuntos de credenciais. Um conjunto destinado identicao do cliente e outro identicao do dono do recurso a ser requisitado [16]. O protocolo segue o seguinte uxo: 1. Token de Requisio. Quando o usurio entra na aplicao consumidora, esta requisita ao servidor um token de requisio. Quando a aplicao consumidora recebe o token, ela redireciona o usurio para a tela de autenticao do servidor. O token de requisio enviado, bem como um link para redirecionamento, assim que o usurio autenticar-se. 2. Autenticao e Autorizao. Ao ser redirecionado para a tela de autenticao do servidor, o usurio requisitado a autenticar-se. Uma vez autenticado, o usurio recebe um questionamento acerca da autorizao para a aplicao consumidora. 3. Redirecionamento aplicao consumidora. Caso o usurio autorize o acesso, o servidor marca o token de requisio, enviado no passo 1, como autorizado. O usurio ento redirecionado para o URI previamente informada pela aplicao consumidora.
No OAuth, o cliente ou consumidor a aplicao que est requisitando os recursos privados. O site que os fornece chamado de servidor ou provedor do servio. O usurio chamado de dono do recurso.
2

Redes Sociais e APIs

4. Token de acesso. Quando o uxo retorna aplicao consumidora, ela encarrega-se de fazer um intercmbio do token de requisio por um token de acesso. O token de requisio tem como nico objetivo a aprovao, pelo usurio. Entretanto, o token de acesso destinado s requisies dos recursos privados. 5. Acesso aos recursos privados. Com o token de acesso, a aplicao consumidora pode consultar todos os recursos privados, aos quais o usurio concedeu permisso. O OAuth foi desenvolvido em 2006. Com mais de 3 anos de experincia trabalhando com esse protocolo, em 2009 a comunidade comeou a repens-lo. A verso 2.0 do OAuth [19] um protocolo completamente novo. Sendo assim, ela no garante compatibilidade com as verses anteriores. Essa verso ganhou melhorias em 3 grandes reas em que a verso 1.0 era limitada ou confusa [17]: 1. Autenticao e Assinaturas. A principal falha das tentativas de implementao do OAuth 1.0 foi causada pela complexidade da criptograa requerida na especicao. Mesmo depois de uma reviso, para a verso 1.0a, OAuth continuou no trivial para uso no lado do cliente3 . Para usar a especicao, os desenvolvedores eram obrigados a buscar, instalar e congurar bibliotecas externas. 2. Experincia do Usurio e Opes Alternativas de Emisso de Tokens. OAuth inclui duas partes principais: obteno do token, atravs da autorizao de acesso pelo usurio e uso do token para obteno de recursos protegidos. O mtodo para obteno do token chamado ow. A verso 1.0 do OAuth possuia 3 ows (web, desktop e mobile). Entretanto, a especicao evoluiu posteriormente para um nico ow, que atendia os trs tipos de clientes. Porm, com o aumento do nmero de sites que usam o OAuth, o ow disponvel acabou se tornando cada vez mais limitado. 3. Performance em Escala. Com grandes empresas aderindo ao OAuth, a comunidade chegou concluso de que o protocolo no possua um bom escalonamento. Ele necessitava de gerenciamento de estados atravs de diferentes etapas e requeria a emisso de credenciais de longa durao, que so menos seguras e mais difceis de gerir. Com a verso 2.0 do OAuth foram criados 6 novos ows: User-Agent Flow. Para clientes em navegadores Web. WebServer Flow. Para clientes que so parte de uma aplicao em servidor Web. Device Flow. Adequados para clientes de execuo em dispositivos limitados. Username and Password Flow. Usado quando h um elevado grau de conana entre o usurio e o cliente, para guardar suas credenciais. Client Credentials Flow. O Cliente usa suas credenciais para obter o token de acesso. Assertion Flow. O cliente apresenta uma armao como uma SAML4 para o servidor de autorizao, em troca de um token de acesso.
3 Lado do cliente, nesse contexto, refere-se s linguagens interpretadas pelo navegador, como JavaScript e HTML. 4 Security Assertion Markup Language. Mais detalhes em http://saml.xml.org/

Redes Sociais e APIs

A verso 2.0 do OAuth ainda prov uma opo para autenticao sem criptograa, utilizando HTTPS. As assinaturas foram simplicadas, no sendo mais necessria a anlise, codicao e a ordenao de parmetros. Nesta verso, necessrio apenas uma chave secreta. Tambm so implementados tokens de acesso de curta durao, que so renovados a partir de tokens de atualizao. Isso permite ao cliente requisitar um novo token de acesso, de forma transparente ao usurio. O OAuth 2.0 separa o papel de autenticao e autorizao pelo servidor, da requisio de recursos atravs da API. Isso facilita o uso de servidores distribudos [17].

3.2

API do Facebook

O Facebook possui uma API para leitura e escrita de dados em seu ncleo. Ela chamada de Graph API. Com ela possvel, de maneira simples, requisitar informaes como o relacionamento entre usurios, suas fotos, gostos, eventos, pginas entre outras coisas. Para que uma aplicao consiga acessar as funcionalidades da Graph API necessrio passar por um processo de autorizao. A aplicao s poder consultar informaes de um usurio que a autorizou. Para isso usado o protocolo OAuth (mais detalhes na seo 3.1). A plataforma do Facebook usa a verso 2.0 do OAuth, seguindo o seguinte uxo: 1. Registrar uma aplicao5 . Cada aplicao registrada possui um ID e um cdigo secreto, necessrios para autenticao. 2. Redirecionar o usurio para o processo de autorizao. Para isso necessrio informar o ID da aplicao e um URI para redirecionamento aps a etapa de autorizao, como no exemplo que pode ser visto em Cdigo 1. Cdigo 1 URI de autorizao da API do Facebook.
https://graph.facebook.com/oauth/authorize? client_id=...& redirect_uri=http://www.example.com/oauth_redirect

3. Cdigo de segurana. Se o usurio autorizar a aplicao, ele ser redirecionado para o URI informada no segundo passo. Ser enviado para esse URI um parmetro code. Tal parmetro ser usado para requisitar um token de acesso. 4. Token de acesso. O cdigo de segurana deve ser trocado por um token de acesso. Esse token dever ser enviado para a API em toda requisio que necessite autorizao. Para requisit-lo necessrio enviar o ID da aplicao, seu cdigo secreto, o cdigo de segurana e o URI para redirecionamento. Como no exemplo exibido em Cdigo 2. Cdigo 2 Requisitando Token de acesso, para aplicaes, da API do Facebook.
https://graph.facebook.com/oauth/access_token? client_id=...& redirect_uri=http://www.example.com/oauth_redirect& client_secret=...& code=...
5

Link para registro de aplicaes no Facebook: http://developers.facebook.com/setup/

Redes Sociais e APIs

Se, no passo 3, o usurio no autorizar a aplicao, o mesmo URI de redirecionamento ser chamada. Entretanto, ser enviado o parametro error_reason. A autenticao, conforme descrita acima, garante acesso s informaes pblicas do usurio. As informaes pblicas so aquelas que esto acessveis em seu perl, para qualquer outro usurio. Elas incluem o nome, a foto do perl, a lista de amigos entre outras coisas. Entretanto, a aplicao pode necessitar de maior permisso. Para isso o Facebook possui alguns grupos de permisses estendidas. Acesso ao lbum de fotos do usurio, gerenciamento de eventos e pginas, postar no mural de recados e acesso ao chat so exemplos de funes privadas e requerem permisses estendidas. Para requisit-las, um parmetro extra (scope) deve ser enviado no processo de autorizao. O exemplo presente em Cdigo 3 substitui o URI a ser chamado no exemplo do passo 2. Cdigo 3 Requisitando acesso com permisses estendidas, na API do Facebook.
https://graph.facebook.com/oauth/authorize? client_id=...& redirect_uri=http://www.example.com/callback& scope=user_photos,user_videos,publish_stream

O exemplo em Cdigo 3 requisitar ao usurio 3 permisses estendidas para a aplicao. Acessar suas fotos, vdeos e publicar em seu mural, respectivamente. Uma lista completa das permisses estendidas pode ser obtida em [8]. A tela de login e a requisio de permisses estendidas so feitas a partir de uma janela pop-up. Entretanto, para maior interoperabilidade, pode ser enviado o parmetro display pelo URI. Esse parmetro pode assumir os valores page, para autenticao em uma nova pgina, popup, para janela em pop-up, wap para uma verso WAP, otimizada para dispositivos mveis e touth para smartphones como Android e iPhone. Para obter dados acerca de aplicaes, no preciso autorizao de usurio. Para isso, h um procedimento mais simplicado. O token de acesso pode ser requisitado como no exemplo exibido no Cdigo 4. Cdigo 4 Requisitando Token de acesso, para aplicaes, da API do Facebook.
https://graph.facebook.com/oauth/access_token? client_id=...& client_secret=...& type=client_cred

O diferencial o parmetro type. O token retornado poder ser usado como no exemplo presente no cdigo 5. Cdigo 5 Usando Token de acesso da API do Facebook.
https://graph.facebook.com/app_id/insights?access_token=...

No exemplo acima, app_id o ID da aplicao. Esse exemplo requisita dados estatsticos acerca do uso da aplicao. Todos os retornos da API so feitos no formato JSON. Um formato para representao textual de dados de maneira leve e simplicada, baseado na sintaxe do JavaScript[1]. Para facilitar o uso da API, o Facebook dispe de alguns Kits de Desenvolvimento (SDKs). Existe kits

Redes Sociais e APIs

para as linguagens de programao JavaScript, PHP e Python e para os sistemas operacionais, de smartphones, iOS e Android. No Cdigo 6 possvel ver um exemplo de uso do JavaScript SDK para listar os nomes de amigos do usurio logado. O cdigo embutido em um HTML e possui internacionalizao. Para mudar o idioma, basta trocar pt_BR na linha 1 pelo idioma a ser escolhido. Cdigo 6 Requisitando Lista de Amigos com JavaScript SDK
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

<script src="http://connect.facebook.net/pt_BR/all.js"></script> <script> FB.init({ appId : 138213456214689, // ID da aplicao status : true, // verificar se est logado cookie : true, // ativar cookies (sesses) xfbml : true // interpretar XFBML }); function listarAmigos(response) { if (response.session) { // Usurio est logado, lista os nomes de seus amigos FB.api(/me/friends, function(response) { var amigos = response.data; for(i in amigos) { document.getElementById(saida) .innerHTML += amigos[i].name+"<br/>"; } }); } else { // Usurio no est logado, pede para ele logar-se alert(Desculpe, necessrio fazer login.); FB.login(function(response) { listarAmigos(response); }); } } // Verificar se usurio j est logado FB.getLoginStatus(function(response) { listarAmigos(response); }); </script>

A API do Facebook tambm possui uma linguagem para consulta de dados. Parecida com o SQL, ela chamada de FQL (Facebook Query Language). O exemplo do Cdigo 7 retorna o nome, a foto e o gnero de um usurio. Cdigo 7 Exemplo de uso da FQL na API do Facebook.
https://api.facebook.com/method/fql.query? query=SELECT name, pic, sex FROM user WHERE uid = 1820391700

A FQL pode retornar os dados no formato XML ou JSON. O padro XML. Para especicar o formato, basta enviar o parmetro format com valor igual a xml ou json. Uma lista

Redes Sociais e APIs

10

completa de tabelas e campos pode ser obtida em [7]. Tambm h uma linguagem de marcao, chamada de FBML (Facebook Markup Language). Para us-la necessrio criar uma pgina interna ao Facebook ou usar o JavaScript SDK. Na linha 7 do Cdigo 6, ativado o interpretador de FBML. Uma lista completa com todas as tags da FBML pode ser consultada em [6].

3.3

API do Twitter

A API do Twitter consiste em trs partes. Duas delas so APIs Web baseadas no REST e uma para uxo contnuo de dados (Streaming). Como dito anteriormente na Seo 2.1, no Twitter cada usurio possui um histrico de pequenas mensagens sobre coisas que esto acontecendo ou que ele est sentindo. As duas APIs baseadas em REST, esto inteiramente relacionadas com o histrico. H uma API para buscas (Search API) e outra para manipulao dos dados. A API de uxo contnuo (Streaming API), possui arquitetura diferente das demais, com conexes de longa durao [29] [26] [10]. Para autenticao e autorizao, a API do Twitter tambm utiliza o protocolo OAuth. Entretanto, na verso 1.0a. Essa verso mais "burocrtica"que a verso 2.0 (como visto na seo 3.1), sendo necessrio o envio de informaes no cabealho HTTP de requisio. A API do Twitter segue o seguinte uxo [29]: 1. Registrar uma aplicao6 . Cada aplicao registrada possui uma chave de API (API Key), uma chave de consumidor (Consumer Key) e um cdigo secreto de consumidor (Consumer Secret), necessrios para autenticao. 2. Token de requisio. Esse token necessrio para a autenticao. Ele ser trocado pelo token de acesso posteriormente. Para requisit-lo necessrio passar alguns parmetros: oauth_nonce: Uma chave aleatria usada para prevenir ataques. oauth_callback: Um URI para redirecionamento aps a obteno do token de requisio. No exemplo abaixo foi utilizado o URI http://localhost/ process_callback. oauth_consumer_key: A chave de consumidor, adquirida no cadastro da aplicao. oauth_version: A verso do OAuth a ser usado (2.0 ainda no est implementado). oauth_signature_method: O mtodo de criptograa para a assinatura. Atualmente o Twitter suporta apenas HMAC-SHA17 oauth_timestamp: O timestamp atual, em formato Unix. oauth_signature: Uma assinatura gerada a partir da concatenao do mtodo de requisio com o URI requisitado e os parmetros passados, em ordem alfabtica. Os parmetros devem ser colocados no padro URL-enconde, como no exemplo presente no Cdigo 8.
Link para registro de aplicaes no Twitter: http://dev.twitter.com/apps HMAC uma sigla para Hash-based Message Authentication Code. HMAC-SHA1 uma criptograa sem volta que usa o algortimo SHA1 e uma chave.
7 6

Redes Sociais e APIs

11

Cdigo 8 Exemplo de string para gerao do parmetro oauth_signature.

POST& https\%3A\%2F\%2Fapi.twitter.com\%2Foauth\%2Frequest_token& oauth_callback\%3Dhttp\%253A\%252F\%252Flocalhost\%252F process_callback\%26 oauth_consumer_key\%3DGDdmIQH6jhtmLUypg82g\%26 oauth_nonce\%3DQP70eNmVz8jvdPevU3oJD2AfF7R7odC2XJcn4XlZJqk\%26 oauth_signature_method\%3DHMAC-SHA1\%26 oauth_timestamp\%3D1272323042\%26 oauth_version\%3D1.0

A assinatura consiste no hash gerado pela concatenao acima, a partir do algoritmo informado no parmetro oauth_signature_method. O algortimo usado pelo Twitter necessita de chave. Com isso, usada a Consumer Secret da aplicao, nesse momento, para gerao da assinatura. O token de requisio obtido atravs do URI https://api.twitter.com/ oauth/request_token. Os parmetros so passados pelo cabealho Authorization do protocolo HTTP, como no exemplo exibido no Cdigo 9. Cdigo 9 Cabealho Authorization do protocolo HTTP, passado pelo OAuth.
OAuth oauth_nonce="QP70eNmVz8jvdPevU3oJD2AfF7R7odC2XJcn4XlZJqk", oauth_callback="http\%3A\%2F\%2Flocalhost\%2Fprocess_callback", oauth_signature_method="HMAC-SHA1", oauth_timestamp="1272323042", oauth_consumer_key="GDdmIQH6jhtmLUypg82g", oauth_signature="8wUi7m5HFQy76nowoCThusfgB\%2BQ\%3D", oauth_version="1.0"

O retorno dessa requisio uma string com 3 parmetros concatenados. oauth_token, o token de requisio; oauth_token_secret, uma chave secreta que ser usada no passo 4 e oauth_callback_confirmed, que informa se o URI de retorno foi entendido corretamente. 3. Autorizando a aplicao pelo usurio. O token obtido no passo anterior dever ser enviado para o URI de autenticao/autorizao. O URI pode ser https:// api.twitter.com/oauth/authorize ou https://api.twitter.com/ oauth/authenticate. A diferena est no fato de que com o mtodo oauth/authorize o usurio ter que conrmar a autorizao em todas as requisies, enquanto que com o mtodo oauth/authenticate o usurio s precisa autorizar a aplicao uma vez. Caso no haja usurio logado, ser exibido um formulrio para login de usurio. Aps sua autenticao, o usurio requisitado autorizar a aplicao. Uma vez autorizado o acesso, o uxo redirecionado para o URI de retorno informado no passo 2. Nesse redirecionamento so enviados dois parmetros: oauth_token e oauth_verifier, que sero usados no prximo passo. 4. Token de acesso. Com a autorizao pelo usurio, o ltimo passo obter um token que ser usado em todas as requisies futuras. Para isso, feita uma requisio semelhante ao

Redes Sociais e APIs

12

do passo 2, para o URI https://api.twitter.com/oauth/access\_token, com os seguintes parmetros: oauth_nonce: Uma chave aleatria usada para prevenir ataques. oauth_consumer_key: A chave de consumidor, adquirida no cadastro da aplicao. oauth_version: A verso do OAuth a ser usado (2.0 ainda no est implementado). oauth_signature_method: O mtodo de criptograa para a assinatura. Atualmente o Twitter suporta apenas HMAC-SHA18 oauth_timestamp: O timestamp atual, em formato Unix. oauth_token: O token de requisio, reenviado para o URI de retorno no passo anterior. oauth_verifier: Um cdigo vericador, gerado pela autorizao do usurio. Esse cdigo enviado ao URI de retorno, no passo anterior. oauth_signature: Uma assinatura gerada a partir da concatenao do mtodo de requisio com o URI requisitado e os parmetros passados, em ordem alfabtica. Os parmetros devem ser colocados no padro URL-enconde, como no exemplo exibido no Cdigo 10.

Cdigo 10 Exemplo de string para gerao do parmetro oauth_signature para Token de acesso.
POST& https\%3A\%2F\%2Fapi.twitter.com\%2Foauth%2Faccess_token& oauth_consumer_key\%3DGDdmIQH6jhtmLUypg82g\%26 oauth_nonce\%3D9zWH6qe0qG7Lc1telCn7FhUbLyVdjEaL3MO5uHxn8\%26 oauth_signature_method\%3DHMAC-SHA1\%26 oauth_timestamp\%3D1272323047\%26 oauth_token\%3D8ldIZyxQeVrFZXFOZH5tAwj6vzJYuLQpl0WUEYtWc\%26 oauth_verifier\%3DpDNg57prOHapMbhv25RNf75lVRd6JDsni1AJJIDYoTY\%26 oauth_version\%3D1.0

Novamente, gerado um hash da concatenao e ele a assinatura. Entretanto, agora a chave para a criptograa ser a concatenao entre o Consumer Secret e o oauth_token_secret, obtido no passo 2. O retorno da requisio composto pelo token de acesso, uma palavra chave secreta, o ID e o nome do usurio que autorizou a aplicao. Pode-se observar que as requisies realizadas no Twitter, para autenticao e autorizao, no so comuns. Isso se d pelo uso da verso 1.0 do protocolo OAuth. Para fazer requisies como essas, necessrio um cliente em que seja possvel a edio do cabealho HTTP. O cURL9 uma biblioteca interessante para essa funcionalidade. Os cdigos 11 e 12 utilizam essa biblioteca em conjunto com a linguagem de programao PHP, como exemplo.
HMAC uma sigla para Hash-based Message Authentication Code. HMAC-SHA1 uma criptograa sem volta que usa o algortimo SHA1 e uma chave. 9 Mais detalhes em http://curl.haxx.se/
8

Redes Sociais e APIs

13

Cdigo 11 Script PHP para obteno de tokens usando a funo sendOAuthReq (cdigo 12)
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52

<?php // Incluindo funo sendOAuthReq include sendOAuthReq.php; // Ser usada a sesso para armazenar o token_secret session_start(); // Valores dados pela API do Twitter apos registro em // http://twitter.com/oauth define(CONSUMER_KEY, "hV6j6CnFFAfCgnzGk3D4A"); define(CONSUMER_SECRET, "f1NzKXPp0v8HXe7UqWVjxczaarRS2TwCTHM1ZxCk"); // Se tiver sido enviado o parmetro oauth_token // tentar obter o token de acesso if($_GET[oauth_token]) { // URL para requisio do token de acesso $url = "https://twitter.com/oauth/access_token"; // Token de requisio e verificador sero enviados $param[oauth_token] = $_GET[oauth_token]; $param[oauth_verifier] = $_GET[oauth_verifier]; // Faz requisio pelo token de acesso e trata resposta $resposta = sendOAuthReq($url, $param); parse_str($resposta, $api); // Token de acesso; echo $api[oauth_token]; // Destroi a sesso e encerra o script session_destroy(); die; } // URL para obteno do token de requisio $url = "https://twitter.com/oauth/request_token"; // Faz requisio passando a URL de retorno desejada $param[oauth_callback] = "http://localhost/mestrado/twitter.php"; $resposta = sendOAuthReq($url, $param); parse_str($resposta, $api); // Armazena o token secret na sesso $_SESSION[secret] = $api[oauth_token_secret]; // Cria link para autorizao, com o token de requisio ?> <a href="https://twitter.com/oauth/authenticate? oauth_token=<?php echo $api[oauth_token]?>"> Autorizar no Twitter </a>

Redes Sociais e APIs

14

Cdigo 12 Funo PHP para envio de requisies OAuth utilizando cURL

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47

<?php function sendOAuthReq($url, $param, $post = false) { //Parmetros comuns nas requisies $param[oauth_consumer_key] = CONSUMER_KEY; $param[oauth_version] = "1.0"; $param[oauth_timestamp] = time(); $param[oauth_signature_method] = "HMAC-SHA1"; $param[oauth_nonce] = md5(uniqid(rand(), true)); // Ordenar parametros ksort($param); // Monta a chave e codifica com HMAC_SHA1 $sign = POST&. rawurlencode($url)."&". rawurlencode(http_build_query($param). // Caso tenha parmetros a ser enviados // por POST, concatena-os. (($post) ? "&".http_build_query($post) : "")); $sign = base64_encode( hash_hmac(sha1, $sign, CONSUMER_SECRET."&".$_SESSION[secret], true ) ); $param[oauth_signature] = $sign; // Monta cabealho Authorization com os parmetros $authHeader = "Authorization: OAuth ". http_build_query($param, null, ","); // Requisita a URL, enviando os parametros com cURL $curlHandle = curl_init(); curl_setopt($curlHandle, CURLOPT_URL, $url); curl_setopt($curlHandle, CURLOPT_RETURNTRANSFER, 1); curl_setopt($curlHandle, CURLOPT_HTTPHEADER, array($authHeader)); curl_setopt($curlHandle, CURLOPT_POST, true); if($post) { curl_setopt($curlHandle, CURLOPT_POSTFIELDS, http_build_query($post)); } $apiResponse = curl_exec($curlHandle); curl_close($curlHandle); return $apiResponse; } ?>

A API do Twitter ainda possui uma outra forma de autorizao, que no usa OAuth. Essa

Redes Sociais e APIs

15

forma bem simplicada, chamada de Basic Authentication. Consiste no envio do usurio e senha pelo cabealho HTTP. Essa autenticao insegura e est em desuso. Por isso, no ser descrita neste estudo [26]. A API de busca (Search API) no necessita de autenticao pelo usurio. Ela pode ser usada, mesmo que no haja alguma aplicao registrada e vinculada s requisies. Essa API possui apenas o mtodo search. Ela est separada do restante da API, por ter sido desenvolvida inicialmente fora do Twitter, por uma empresa chamada Summize. Entretanto, em 2008 o Twitter comprou tal empresa. Existem planos para unicao das duas APIs REST [29]. O mtodo search faz buscas e retorna-as em 4 possveis formatos: xml, json, rss e atom. Ele pode ser requisitado a partir do URI: http://search.twitter.com/search. format, sendo que format pode assumir um dos 4 formatos disponveis. A expresso para busca enviada atravs do parmetro q. O mecanismo de busca da Search API otimizado e mistura resultados populares com resultados recentes. Entretanto, isso pode ser alterado a partir do parmetro result_type. Ele pode ser denido como mixed (padro), popular ou recent. Tambm h o parmetro geocode para busca de twitter a partir da localizao geogrca do usurio, entre outros. A API principal do Twitter responsvel pela manipulao e consulta dos dados. Qualquer mtodo dessa API precedido do URI http://api.twitter.com/version/, sendo que version a verso da API (atualmente 1). Nessa API, alguns mtodos no requerem autorizao/autenticao. Os mtodos que trazem informaes disponveis no site do Twitter para qualquer visitante (no logado), no requerem autorizao. Para esses mtodos, suciente fazer uma requisio HTTP convencional, para seu URI. Um exemplo o mtodo statuses/user_timeline. Tal mtodo retorna os ltimos envios de um usurio em ordem cronolgica. possvel especicar qual o usurio atravs dos parmetros user_id, enviando o ID ou screen_name, enviando o login do usurio. O mtodo trends tambm no requer autorizao. Ele retorna palavras que so tendncias (muito faladas) no Twitter. Esse mtodo possui os sub-recursos: trends/current, que retorna os termos mais falados atualmente; trends/daily, que mostra as expresses mais populares em um dia especco e trends/weekly para uma semana especca. Tambm h ltros por localidade, a partir do recurso trends/available, que pode receber latitude (lat) e longitude (long) como parmetros. Os mtodos que requerem autenticao devem ser requisitados de maneira semelhante s requisies para obteno do token de acesso. Os parmetros comuns em qualquer requisio so oauth_consumer_key, oauth_nonce, oauth_timestamp, oauth_version e oauth_signature_method, j descritos. Tambm necessrio enviar o parmetro oauth_token, com o token de acesso previamente obtido. Esses parmetros so enviados pelo cabealho Authorization. Os parmetros especcos do mtodo requisitado so enviados por POST. A assinatura formada conforme descrito anteriormente. Entretanto, tambm so concatenados os parmetros passados por POST. A chave para a criptograa composta pelo Consumer Secret e o oauth_token_secret obtido com o token de acesso. O Cdigo 13 exibe um exemplo de requisio ao mtodo statuses/update, usando a funo sendOAuthReq do Cdigo 12. Esse mtodo insere um novo post na timeline do usurio autenticado10 .
Uma lista completa com todos os mtodos disponveis na API do Twitter pode ser vista em: http://dev. twitter.com/doc/.
10

Redes Sociais e APIs

16

Cdigo 13 Script PHP que chama mtodo statuses/update usando a funo sendOAuthReq (cdigo 12)
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28

<?php include sendOAuthReq.php; // Valores dados pela API do Twitter apos registro em // http://twitter.com/oauth define(CONSUMER_KEY, "hV6j6CnFFAfCgnzGk3D4A"); define(CONSUMER_SECRET, "f1NzKXPp0v8HXe7UqWVjxczaarRS2TwCTHM1ZxCk"); // Definindo token de acesso e chave secreta define(ACCESS_TOKEN, $_GET[oauth_token]); define(ACCESS_TOKEN_SECRET, $_GET[oauth_token_secret]); $_SESSION[secret] = ACCESS_TOKEN_SECRET; // Mtodo a ser requisitado $url = "http://api.twitter.com/1/statuses/update.json"; $param[oauth_token] = ACCESS_TOKEN; // Incluso de novo post na timeline $post[status] = utf8_encode("Novo post na timeline do Twitter."); $retorno = sendOAuthReq($url, $param, $post); // Recebe retorno em JSON e coloca-o em objeto JavaScript ?> <script> retorno = <?php echo $retorno; ?>; </script>

A API de uxo contnuo (Streaming API) possui mtodos para busca e exibio dos posts de usurios. Todos os mtodos dessa API requerem autorizao, sendo que alguns requerem contato direto com os desenvolvedores da API para liberao. Os ltros so semelhantes aos presentes na API de busca. Entretanto, o uxo contnuo. Isso signica que, a medida que os usurios vo enviando posts, a API atualizada os dados para consulta, incluindo novos resultados, sem a necessidade de novas requisies. O nico formato permitido nessa API o JSON11 [26].

3.4

API do Flickr

Como adicional em relao maioria das APIs de Redes Sociais Online, a API do Flickr suporta alm da arquitetura REST, o SOAP e o XML-RPC. Entretanto, neste trabalho, ser utilizada a arquitetura REST, em busca de maior semelhana e integrao com as demais APIs. O Flickr trabalha com um protocolo de autenticao/autorizao proprietrio, semelhante ao OAuth. Tal protocolo foi um dos utilizados como inspirao para a elaborao do OAuth [17].
Uma lista completa com todos os mtodos disponveis na API de uxo contnuo do Twitter pode ser vista em: http://dev.twitter.com/pages/streaming_api_methods.
11

Redes Sociais e APIs

17

Como nas demais, na API do Flickr necessrio cadastrar uma aplicao12 . Com o registro da aplicao, so criados uma chave e um segredo. Caso a aplicao seja Web, necessrio congurar um URL de retorno (callback). A autenticao segue o seguinte uxo [20]: 1. Cdigo frob. Inicialmente feita uma requisio para o URI http://flickr.com/ services/auth/. So enviados 3 parmetros. O parmetro api_key envia a chave da aplicao. O api_sig, deve ter como valor a assinatura desta requisio (gerada a partir do procedimento presente no passo 2). O perms, com o nvel de permisses desejado para a aplicao. Esse parmetro pode assumir 3 valores: read , para leitura de dados; write para insero/atualizao de dados e delete para excluso de dados. Cada nvel possui a permisso de seus antecessores. Logo, o nvel delete possui write e read. Caso o usurio no esteja logado exibido um formulrio de login. Em seguida, o usurio requisitado a aceitar ou negar autorizao aplicao. Caso o usurio aceite, a requisio redireciona o uxo para o URL de retorno, enviando o parmetro frob. 2. Assinatura. Para gerar a assinatura necessria no passo anterior, primeiramente ordenase alfabeticamente os parmetros a serem enviados. Em seguida, o segredo da aplicao concatenado com os parmetros e seus respectivos valores. A partir da expresso resultante, calculado o hash MD513 . Esse hash ser a assinatura. 3. Obtendo token de acesso. O aplicativo dever ento chamar o mtodo flickr.auth.getToken da API. Os mtodos da API do Flickr so requisitados a partir do URI http://flickr.com/services/rest/, para a arquitetura REST. O mtodo desejado informado pelo parmetro method. Este mtodo requer 3 parmetros. A chave da aplicao, o cdigo frob e uma assinatura, seguindo o mesmo procedimento do passo 2. A resposta ter um token para futuras chamadas de mtodos. Existem alguns mtodos na API do Flickr que no necessitam de autorizao. Entretanto, mesmo para estes necessrio enviar a chave da aplicao. O mtodo flickr.photos.search um exemplo. Ele tem como objetivo a busca por fotos em toda a base do Flickr. Este mtodo possui uma srie de parmetros para ltros opcionais14 . No Cdigo 14 pode ser visto um exemplo de URI para requisit-lo. Cdigo 14 Exemplo de URI, no Flickr, para o mtodo flickr.photos.search.
http://www.flickr.com/services/rest/? method=flickr.photos.search& api_key=...& tags=Goiania,Praa& format=json

O URI acima retorna uma lista, em formato JSON, de dados de fotos que possuem as tags "Goinia"e "Praa". A paginao congurada pelos parmetros page e per_page,
O registro de aplicaes para uso da API do Flickr pode ser feito em: http://www.flickr.com/ services/apps/. necessria uma conta de e-mail no Yahoo. 13 MD5, Message-Digest algorithm 5, um algoritmo de hash (criptograa sem volta) de 128 bits, desenvolvido pela RSA Data Security, Inc. e descrito na RFC 1321. 14 A lista completa de parmetros do mtodo flickr.photos.search est disponvel em: http://www. flickr.com/services/api/flickr.photos.search.html
12

Redes Sociais e APIs

18

com valores padres de 1 e 100 respectivamente. O parmetro format opcional, sendo que o padro XML. Este parmetro est presente em qualquer mtodo da API. Parmetros geogrcos tambm esto disponveis, como no exemplo exibido no Cdigo 15: Cdigo 15 Exemplo de URI, no Flickr, com parmetros geogrcos.
http://www.flickr.com/services/rest/? method=flickr.photos.search& api_key=...& text=paisagens& extras=geo,tags,description& lat=-16.71&lon=-49.20&radius=32

Neste exemplo feita a busca por fotos que contenham a palavras "paisagens"no ttulo, descrio ou tags e estejam geo-referenciadas nas coordenadas da cidade de Goinia. Os parmetros lat e lon renam a busca em uma determinada localidade geogrca. O parmetro radius informa o tamanho do raio em torno da coordenada informada (por padro em km), em que ser feita a busca. O parmetro extras informa campos adicionais a serem retornados na busca. Para requisitar uma foto (e no apenas seus dados) utilizada a sintaxe de URI exibida no Cdigo 16: Cdigo 16 Sintaxe de URI para requisio de fotos do Flickr.
http://farm{farm-id}.static.flickr.com/{server-id}/{id}_{secret}.jpg

Os valores entre chaves so parmetros obtidos atravs do retorno do mtodo de busca, conforme pode ser visto no Cdigo 17. Cdigo 17 Exemplo de tag do XML de retorno e URI para foto.
// Exemplo de tag do XML de retorno: <photo id="1318815545" owner="10298760@N03" secret="0a1a634be8" server="1439" farm="2" ... /> // URI para a foto: http://farm2.static.flickr.com/1439/1318815545_0a1a634be8.jpg

Existem mtodos que referem-se aos dados do usurio autenticado. Para esses mtodos necessrio conceder permisso read. Um exemplo o mtodo flickr.contacts.getList, que retorna uma lista de contatos do usurio logado. H o parmetro opcional filter que ltra a busca por amigos, famlia, ambos ou outros. Abaixo um exemplo de como utiliza-lo: http://www.flickr.com/services/rest/? method=flickr.contacts.getList& api_key=...& auth_token=...& filter=family& api_sig=...

Redes Sociais e APIs

19

O URI acima retorna todos os contatos que esto marcados como famlia. possvel notar que so enviados a chave da aplicao, o token de acesso obtido na autenticao e a assinatura da requisio. Todos os mtodos que requerem autorizao, necessitam do envio desses 3 parmetros [2]. Os mtodos que atualizam dados ou interagem com outros usurios (comentrios, "favoritar", adicionar notas) requerem permisso write. Um exemplo o mtodo flickr.photos.setMeta. Este mtodo tem o objetivo de alterar o ttulo e a descrio de uma foto. Devem ser enviados para esse mtodo os parmetros photo_id, com o id da foto; title, com o novo ttulo da foto e description, com a nova descrio da foto. Mtodos com permisso write, como esse, exigem solicitao HTTP POST. Para excluso de dados necessria a permisso delete. Ao se autenticar e autorizar esse nvel de permisso, o usurio concede aplicao poder de excluso de suas fotos e vdeos. Um exemplo de mtodo que requer esse nivel de permisso o flickr.photos.delete. Este mtodo necessita do ID da foto que ser excluda. interessante observar que alguns mtodos de excluso como flickr.favorites.remove, para excluso de favoritos e flickr.photos.comments.deleteComment para excluso de comentrios em uma foto, no necessitam de permisso delete. Mtodos de excluso que esto envolvidos apenas com a interao entre os usurios e no excluem recursos (fotos e vdeos), precisam apenas de permisso write. Uma lista completa dos mtodos da API do Flickr pode ser obtida em [11].

3.5

OpenSocial

Diferentemente das APIs descritas anteriormente, o OpenSocial um conjunto de APIs que possui como principal objetivo a interoperabilidade de aplicaes em sites de rede social. Tais APIs descrevem um "modelo"de plataforma para desenvolvimento de aplicativos em redes sociais online. Os sites de redes sociais que implementam as APIs descritas pelo OpenSocial so chamados de recipientes. Os aplicativos desenvolvidos em OpenSocial funcionam em qualquer recipiente que suporte a verso em que este foi desenvolvido. Atualmente, mais de 40 sites de redes sociais so recipientes para o OpenSocial15 [4]. Esto entre estes, sites como o Orkut, o MySpace, o LinkedIn, o Yahoo! e o Friendster. Entretanto, cada site implementa o OpenSocial em uma verso diferente. As verses mais atuais do compatibilidade com as mais antigas, sendo que a atual a 0.9. A API completamente baseada em XML, HTML e JavaScript [4]. Com o OpenSocial, a aplicao ca encapsulada no site de rede social recipiente. Logo, questes de autenticao e autorizao, para a aplicao, so denidas separadamente, no prprio recipiente. Entretanto, o OpenSocial possui suporte OAuth, com foco na autorizao para aplicaes externas acessarem dados da aplicao desenvolvida em OpenSocial [15]. As aplicaes desenvolvidas em OpenSocial consistem em um arquivo XML com chamadas arquivos JavaScript e HTML, caso necessrio. Tal arquivo XML centraliza as informaes gerais sobre a aplicao. No cadastro de uma aplicao em OpenSocial, em um recipiente, deve ser informado o caminho para este arquivo XML. O Cdigo 18 exibe um exemplo simples de aplicao OpenSocial. Toda aplicao deve ter, como raiz, a tag Module. Em ModulePrefs so informadas as conguraes e preferencias da aplicao, como cone, imagem de exibio, nome, ttulo, autor, lngua padro, entre outras coisas. O exemplo do Cdigo 18 apenas exibe a mensagem "Ol Mundo!"em uma aplicao de nome "Teste - INF/UFG"e descrio "Teste de OpenSocial".
15

A lista completa de recipientes para o OpenSocial pode ser vista em: http://wiki.opensocial.org/

Redes Sociais e APIs

20

Cdigo 18 Cdigo bsico para gerao de aplicao em OpenSocial

1 2 3 4 5 6 7 8 9 10 11 12

<?xml version="1.0" encoding="UTF-8" ?> <Module> <ModulePrefs title="Teste - INF/UFG" description="Teste de OpenSocial"> <Locale lang="pt" country="br" /> </ModulePrefs> <Content type="html"> <![CDATA[ Ol, Mundo! ]]> </Content> </Module>

A API em JavaScript do OpenSocial inclui dois namespaces16 : opensocial.* e gadgets.*. O primeiro diz respeito a classes e funes relacionadas congurao do aplicativo. O segundo, possui as classes e mtodos mais especcos do aplicativo, que dizem respeito a visualizao e mensagens. A API em JavaScript do OpenSocial possui dois "personagens": OWNER e VIEWER. OWNER refere-se ao dono da aplicao, aquele que a registrou. VIEWER refere-se ao usurio que est vendo a aplicao no momento em que ela executada. No OpenSocial, os aplicativos costumam ser chamados de Gadgets. Esse termo refere-se pequenos softwares que podem ser agregados em um ambiente maior. Nos Cdigos 19 e 20 h um exemplo de aplicativo OpenSocial que lista os amigos do usurio visualizados da aplicao. Cdigo 19 Aplicao em OpenSocial para Listagem de Amigos
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

<?xml version="1.0" encoding="UTF-8" ?> <Module> <ModulePrefs title="Teste - INF-UFG" description="Teste de OpenSocial" author_email="otaviocx@gmail.com" screenshot="" thumbnail=""> <Require feature="opensocial-0.8" /> </ModulePrefs> <Content type="html"> <![CDATA[ <script type="text/javascript"> // JavaScript ser inserido aqui </script> <div id="conteudo"> <div id="titulo"></div> <div id="amigos"></div> </div> ]]> </Content> </Module>

16

No JavaScript, namespaces so pacotes de classes e funes relacionadas.

Redes Sociais e APIs

21

Cdigo 20 Aplicao em OpenSocial para Listagem de Amigos - JavaScripts

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49

function loadFriends() { // cria uma nova requisio para a API var req = opensocial.newDataRequest(); // os dados do VIEWER sero requisitados e // armazenados no parametro viewer req.add(req.newFetchPersonRequest( opensocial.IdSpec.PersonId.VIEWER ), viewer); // configura a requisio dos amigos de VIEWER var viewerFriends = opensocial.newIdSpec( { "userId" : "VIEWER", "groupId" : "FRIENDS" } ); // os dados dos amigos sero armazenados em viewerFriends req.add( req.newFetchPeopleRequest(viewerFriends), viewerFriends ); // envia a requisio e executa // onLoadFriends aps sua concluso req.send(onLoadFriends); } function onLoadFriends(data) { // coloca os parmetros requisitados em variveis var viewer = data.get(viewer).getData(); var viewerFriends = data.get(viewerFriends).getData(); // exibe um ttulo para o aplicativo com o nome do VIEWER document.getElementById(titulo).innerHTML = "Amigos de "+viewer.getDisplayName(); // monta uma lista HTML com os amigos de VIEWER html = new Array(); html.push(<ul>); viewerFriends.each(function(person) { if (person.getId()) { html.push(<li>, person.getDisplayName(), </li>); } }); html.push(</ul>); // coloca a lista na div amigos document.getElementById(amigos).innerHTML = html.join(); } // loadFriends ser chamada assim que o Gadget carregar gadgets.util.registerOnLoadHandler(loadFriends);

Redes Sociais e APIs

22

O Cdigo 19 um XML com a congurao do aplicativo. Os JavaScripts foram separados no Cdigo 20 para facilitar a visualizao. Neste exemplo existe algumas tags e atributos no presentes no exemplo do Cdigo 18. A tag Require indica ao recipiente quais bibliotecas o aplicativo ir usar, e qual a verso delas. Logo, para criar um aplicativo OpenSocial necessrio informar que este ser usado. Os atributos de ModulePrefs, author_mail, screenshot e thumbnail contm o e-mail do autor, uma captura de tela do aplicativo e uma miniatura, respectivamente. Esses atributos so obrigatrios em alguns recipientes. Dentro da tag Content h duas tags div (titulo e amigos) que sero usadas pelo JavaScript. No JavaScript (Cdigo 20) a requisio congurada e feita pela funo loadFriends. Aps a concluso da requisio, a funo onLoadFriends chamada. Tal funo monta uma lista HTML com os amigos do usurio visualizador e um ttulo com o nome do usurio visualizador. O resultado pode ser visto na Figura 2, para os recipientes Orkut (em cima) e MySpace.

Figura 2: Visualizao de aplicao OpenSocial no Orkut (em cima) e MySpace. Para facilitar a criao e adaptao de novos recipientes para o OpenSocial, a Apache criou o Shindig[12]. Trata-se de um projeto de cdigo fonte aberto para referncia na implementao dos padres OpenSocial. Ele contem tanto o cdigo fonte para o servidor quanto o do cliente. O Shindig tambm pode ser usado para testes locais de aplicativos OpenSocial.

Redes Sociais e APIs

23

3.6

OpenID

O OpenID, em sua verso 1.0, possua a funcionalidade de um protocolo, para autenticao de URLs, baseado em HTTP. Seu objetivo inicial centralizar a identicao de usurios para autenticao nica em vrios web sites. A partir da verso 2.0, o OpenID tornou-se um arcabouo. Com isso, alm do protocolo para autenticao, o OpenID passou a integrar um protocolo de transferncia de dados e extenses para troca de dados de pers e mensagens usurio-para-usurio. A gura 3 mostra um diagrama em pilha do OpenID. O diagrama mostra um arranjo de tecnologias separadas da seguinte maneira:

Figura 3: Diagrama em pilha do arcabouo OpenID. URLs e XRIs17 formam a base, representando a identicao dos usurios nais; A camada Yadis18 prov a funcionalidade de uma simples descoberta de servios, usando o formato XRDS19 aprovado pela OASIS; OpenID Authentication 2.0 prov uma camada bsica para autenticao unicada, da qual servios de alto nvel dependem. No topo da pilha, outros servios baseados na identicao, como mensagens seguras ou troca de pers podem ser colocados em camadas, dependendo das necessidades especcas da implementao [30]. A identicao feita no OpenID baseada em endereos. Os usurios so identicados por um endereo resolvvel (como URLs ou XRIs). Como o OpenID surgiu em uma poca em que blogs eram comuns, mesmo que URLs no possuam o foco principal de identicao, os URLs de blogs acabaram sendo usadas como identicador de seus autores. Entretanto, o XRI pode ser uma alternativa independente de protocolo, persistente e com privacidade protegida para qualquer identicao [30]. Uma vez que o usurio j possui um endereo digital OpenID, o prximo passo descobrir quais servios a identidade do usurio est associada. Para tal usado o protocolo Yadis. Com ele possvel requisitar um documento XRDS que descreve os recursos usados por um determinado URL ou XRI. O Cdigo 21 mostra um exemplo de documento XRDS. Para identidades
XRI (eXtensible Resource Identier) um formato de resoluo para identicadores abstratos, compatvel com URLs. Possui algumas vantagens em relao s URLs e URIs. Dentre elas destacam-se: o fato de no serem limitados ao protocolo HTTP; distingue acessos a metadados de acessos aos dados do recurso; podem denir um mecanismo de resoluo convel, independente de DNS e podem distinguir entre identicadores persistentes e reatribudos [31]. 18 Yadis um protocolo de comunicao para descoberta de servios. Costuma ser usado para descoberta de servios para identidades digitais [31]. 19 XRDS (eXtensible Resource Descriptor Sequence) um formato, baseado em XML, para descoberta de metadados acerca de um recurso. Um site com autenticao OpenID, pode resolver a identicao de um usurio, a partir de um documento XRDS, am de descobrir a localizao do provedor do servio [31].
17

Redes Sociais e APIs

24

ou servios identicados com XRIs, necessrio registrar o XRI na XDI.org, uma organizao sem ns lucrativos e com conana pblica para organizao de endereos XDI e XRI. Cdigo 21 Exemplo de documento XRDS retornado pelo Yadis.
1 2 3 4 5 6 7 8 9 10

<xrds:XRDS xmlns:xrds="xri://$xrds" xmlns="xri://$xrd*($v*2.0)" xmlns:openid="http://openid.net/xmlns/1.0"> <XRD> <Service> <Type>http://openid.net/signon/1.0</Type> <URI>http://pip.verisignlabs.com/server/openid</URI> </Service> </XRD> </xrds:XRDS>

Na etapa de autenticao, so realizadas uma srie de comunicaes entre o site em que o usurio est se autenticando, chamado de Relying Party, e o provedor do servio OpenID do usurio, chamado Identity Provider. As comunicaes so realizadas de acordo com o seguinte uxo [30]: 1. O usurio entra com o URL da Relying Party (RP) para iniciar o processo de autenticao; 2. RP busca pelo documento Yadis com o identicador provido pelo usurio; 3. RP cria uma palavra chave secreta compartilhada com o Identity Provider (IdP) encontrado por meio da descoberta (passo 2); 4. RP redireciona o navegador para o IdP encontrado por meio da descoberta (passo 2); 5. O usurio entra com seu login e senha no IdP e completa o pedido de conana; 6. IdP redireciona o usurio para a RP com uma prova criptografada de que o usurio dono do URL e de qualquer dado de perl que o usurio escolher liberar; 7. O Usurio redirecionado para a RP e agora est autenticado. O OpenID pode ser totalmente descentralizado. Nenhuma autoridade centralizadora necessria para aprovar o usurio, o site consumidor (RP) ou o provedor da identidade (IdP). Usando uma funcionalidade chamada "delegation", um usurio pode preservar seu identicador OpenID pblico, mesmo que ele troque de provedor de identicao (IdP) [30]. Com a introduo do OpenID Authorization 2.0, os usurios passaram a ter a opo de usar um endereo digital privado. Este endereo pode identic-los localmente, em um consumidor (RP) especco, e no no contexto pblico. O protocolo de transferncia de dados, tambm presente na verso 2.0, prov um mtodo abstrato para intercmbio de dados entre os provedores de identicao e os consumidores.

Redes Sociais e APIs

25

Consideraes Finais

As redes sociais online tm crescido e ganhado grande popularidade na Web. Este conceito gerou um novo foco para a Web: a sociabilizao a partir de relacionamentos online. Alm das funcionalidades para busca de amigos e familiares online, os sites de redes sociais tm sido usado como um novo meio de comunicao. Atualmente, grandes redes sociais online no podem ser consideradas apenas sites. So plataformas para aplicaes sociais. Um conceito novo e crescente na Web. notvel que, mesmo que as aplicaes no possuam inteligncia, possuem funcionalidades no implementveis em aplicaes normais. Isso se d por que, em aplicaes sociais, os usurios fazem parte da aplicao. De forma que quanto mais usurios, melhor ela . Um conceito chamado de inteligencia coletiva [24]. A partir do estudo de APIs de redes sociais online, presente neste trabalho, possvel notar as vrias possibilidades para desenvolvimento de aplicaes sociais. Tecnologias como OAuth, OpenID e OpenSocial, em conjunto, podem construir aplicaes poderosas com interoperabilidade entre redes sociais online, segurana na autorizao e publicao de dados e comodidade na autenticao de usurios. Aliar isso ao poder da Web Semntica pode ser um estudo para trabalhos futuros.

Referncias
[1] Introducing JSON. http://www.json.org/, acessado em Maro de 2010, 2009. [2] Bausch, P.; Bumgardner, J.; Fake, C. Flickr Hacks: Tips & Tools for Sharing Photos Online (Hacks). OReilly Media, Inc., 2006. [3] Boyd, D. M.; Ellison, N. B. Social network sites: Denition, history, and scholarship. Journal of Computer-Mediated Communication, 13(11), 2007. [4] Cole, C.; Russell, C.; Whyte, J. Building OpenSocial Apps: A Field Guide to Working with the MySpace Platform. Addison-Wesley Professional, 2009. [5] Cole, C.; Russell, C.; Whyte, J. Building OpenSocial Apps. Pearson Education, Inc., Boston, MA, US, 2010. [6] Facebook. Facebook developers - facebook markup language (fbml). http:// developers.facebook.com/docs/reference/fbml/, acessado em janeiro de 2011, 2011. [7] Facebook. Facebook developers - facebook query language (fql). http:// developers.facebook.com/docs/reference/fql/, acessado em janeiro de 2011, 2011. [8] Facebook. Facebook developers - permissions. http://developers.facebook. com/docs/authentication/permissions, acessado em janeiro de 2011, 2011. [9] Fielding, R. T. Architectural Styles and the Design of Network-based Software Architectures. PhD thesis, UNIVERSITY OF CALIFORNIA, 2000. [10] Fitton, L.; Gruen, M.; Poston, L. Twitter For Dummies. For Dummies, 2009.

Redes Sociais e APIs

26

[11] Flickr. App garden - api documentation. http://www.flickr.com/services/ api/, acessado em janeiro de 2011, 2011. [12] Foundation, T. A. S. Apache shindig. Apache Incubator, 2010. [13] Fragoso, S. Wtf a crazy brazilian invasion. Fifth International Conference on Cultural Attitudes Towards Technology and Communication, 1:255274, 2006. [14] Gjoka, M.; Kurant, M.; Butts, C. T.; Markopoulou, A. Walking in facebook: a case study of unbiased sampling of osns. In: INFOCOM10: Proceedings of the 29th conference on Information communications, p. 24982506, Piscataway, NJ, USA, 2010. IEEE Press. [15] Grewe, L. OpenSocial Network Programming. Wrox Press Ltd., Birmingham, UK, UK, 2009. [16] Hammer-Lahav, E. The authoritative guide to oauth 1.0. Hueniverse, 2009. [17] Hammer-Lahav, E. Introducing oauth 2.0. Hueniverse, 2010. [18] Hammer-Lahav, E. The oauth 1.0 protocol. Internet Engineering Task Force (IETF), 2010. [19] Hammer-Lahav, E.; Recordon, D.; Hardt, D. The oauth 2.0 protocol. Network Working Group, 2010. [20] Henderson, C.; Cope, A. S.; Costello, E.; Mourachov, S.; Buttereld, S. Flickr authentication api. Flickr App Garden, 2010. [21] Horwitz, R. Google launches opensocial to spread social applications across the web. Google Press Center, 2007. [22] Krishnamurthy, B.; Gill, P.; Arlitt, M. A few chirps about twitter. In: WOSP 08: Proceedings of the rst workshop on Online social networks, p. 1924, New York, NY, USA, 2008. ACM. [23] Kwak, H.; Lee, C.; Park, H.; Moon, S. What is twitter, a social network or a news media? In: WWW 10: Proceedings of the 19th international conference on World wide web, p. 591600, New York, NY, USA, 2010. ACM. [24] Lykourentzou, I.; Vergados, D. J.; Loumos, V. Collective intelligence system engineering. In: MEDES 09: Proceedings of the International Conference on Management of Emergent Digital EcoSystems, p. 134140, New York, NY, USA, 2009. ACM. [25] MacKinnon, I.; Warren, R. Age and geographic inferences of the livejournal social network. In: ICML06: Proceedings of the 2006 conference on Statistical network analysis, p. 176178, Berlin, Heidelberg, 2007. Springer-Verlag. [26] Makice, K. Twitter API: Up and Running Learn How to Build Applications with the Twitter API. OReilly Media, Inc., 2009. [27] Negoescu, R.-A.; Adams, B.; Phung, D.; Venkatesh, S.; Gatica-Perez, D. Flickr hypergroups. In: MM 09: Proceedings of the seventeen ACM international conference on Multimedia, p. 813816, New York, NY, USA, 2009. ACM.

Redes Sociais e APIs

27

[28] Neville, P. LinkedIn Top Success Secrets and Best Practices: LinkedIn Experts Share The Worlds Greatest Tips. Emereo Pty Ltd, London, UK, UK, 2008. [29] Reagan, D. Twitter Application Development For Dummies. For Dummies, 2010. [30] Recordon, D.; Reed, D. Openid 2.0: a platform for user-centric identity management. In: DIM 06: Proceedings of the second ACM workshop on Digital identity management, p. 1116, New York, NY, USA, 2006. ACM. [31] Reed, D.; Chasen, L.; Tan, W. Openid identity discovery with xri and xrds. In: IDtrust 08: Proceedings of the 7th symposium on Identity and trust on the Internet, p. 1925, New York, NY, USA, 2008. ACM. [32] Rivlin, G. Wallower at the web party. The New York Times, Outubro 2006. [33] Tyagi, S. Restful web services. http://java.sun.com/developer/ technicalArticles/WebServices/restful/, acessado em maio de 2010, 2006.