BT

API REST ou API de Grafos? Mudar o nome ajuda?

por Mark Little , traduzido por Alexandre Simundi em 23 Jan 2012 |

Steve Jones, diretor global em gerenciamento de dados da Cap Gemini, vem questionando o sucesso da tecnologia REST no mundo corporativo em vários artigos. Steve acredita que o REST não está morto, mas ainda está nascendo:

A tecnologia SOAP não está morta; está bem viva nas aplicações corporativas é a única forma viável de integrar soluções de uma série de fornecedores (que constituem parcela expressiva do mercado de TI). O REST, entretanto, apresenta menos de 2.500 APIs depois de todos esses anos de desenvolvimento. Chega a ser patético... O REST não está morto nas aplicações corporativas... está apenas nascendo há cinco anos.

Os artigos geraram diversas discussões com opiniões extremadas, mostrando que a decisão por REST ou SOAP ainda é uma preocupação, mesmo anos depois de essas discussões terem começado. Uma conclusão a que se chega é que existem situações em que SOAP funciona bem e outras em que REST é o mais indicado, mas definir precisamente quais são esses cenários muitas vezes causa ainda mais discussões.

Em dezembro de 2011, Steve incrementou a discussão, questionando se uma mudança no nome "REST" poderia melhorar os desentendimentos. Usa como exemplo o que aconteceu no Facebook, que tornou obsoleta a API REST e passou a chamá-la de Graph API. Disse Douglas Purdy, do Facebook:

Não significa que removemos a API, e sim que incentivamos todos os desenvolvedores a usarem a Graph API para novos aplicativos e também a migrar as aplicações existentes para usar a API. De agora em diante, todas as novas funcionalidades estarão disponíveis somente na Graph API e o suporte para essa nova API será maior.

Steve destaca que seria errado usar o exemplo do Facebook como prova de que o REST não serve para a web, porquê ele claramente funciona. Apesar de todos os argumentos na linha "REST contra SOAP", provavelmente a única coisa com a qual quase todos concordam é que o REST funciona e para a web. Além disso, Steve acredita que em vez de problemas técnicos, o Facebook teria na verdade sofrido com convenções de nomenclatura:

O Facebook primeiramente chamou a API the "REST API", mas quando sentiu que isso se tornou um problema, teve duas opções: criar uma nova API chamada "REST API 2.0"; ou criar um novo nome.

Steve Jones defende que o termo "Graph API" é muito mais informativo que REST, pois deixa claro o que o REST tem de bom: formas de percorrer redes de informações complexas e interrelacionadas. Ele afirma que pode existir algum benefício em se distanciar a parte técnica do "fervor religioso" associado com REST (e com SOAP), e conclui:

O termo "Relatórios Orientados a Grafos" (graph-based reporting) poderia ter mais sucesso do que "REST". Teria o Facebook encontrado um termo que incentiva a adoção do REST? Provavelmente não, para integrações entre sistemas, mas a nova terminologia pode ter impacto positivo na área de agregação de informações e geração de relatórios para usuários finais.

Resta saber se um nome diferente pode realmente fazer a diferença, ou se a Graph API é mesmo RESTful; e se for, se vai continuar dessa forma.

Avalie esse artigo

Relevância
Estilo/Redação

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

O nome eu acho que nem importa muito... by Bruno Braga

O que eu acharia legal seria um framework ou padrão único para troca de informações independente de fornecedor.
Algo com o OSLC - Open Services for Lifecycle Collaboration.
O OSLC utiliza REST para troca de dados e o objetivo dele dele é que as ferramentas que fazem parte do ciclo de desenvolvimento troquem dados utilizando a mesma "interface" independente de qual é o fornecedor.
Nesse caso quem quer programar precisa conhecer o OSLC e não a API de um fabricante.

No caso do Facebook e outras redes sociais deveria existir algo como um "Open Services for Social Network" que fosse usado por todas as redes sociais. Com isso o que deveria evoluir com o tempo (versões) seria padrão e não um Graph API 1.0 ou 2.0... =)

Logico que isso é o mundo ideal e talvez um sonho..., mas se já está acontecendo com ferramentas de ALM através do OSLC, quem sabe a moda não pega?

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

1 Dê sua opinião
Feedback geral
Bugs
Publicidade
Editorial
Marketing
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2016 C4Media Inc.
Política de privacidade
BT

We notice you’re using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.