BT

Disseminando conhecimento e inovação em desenvolvimento de software corporativo.

Contribuir

Tópicos

Escolha a região

Início Notícias API REST ou API de Grafos? Mudar o nome ajuda?

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

Favoritos

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

Conteúdo educacional

  • O nome eu acho que nem importa muito...

    by Bruno Braga,

    Seu comentário está aguardando aprovação dos moderadores. Obrigado por participar da discussão!

    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

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

BT