Ole Lensmar, o criador do SoapUI, recentemente questionou se REST está perdendo a atratividade e se são necessárias alternativas. São discutidos diversos pontos em relação a aplicação de REST.
Ole Lensmar, o criador do SoapUI, recentemente questionou se REST está perdendo a atratividade e se são necessárias alternativas:
Nos últimos anos, a adoção de REST como principal método para construção de APIs ofuscou outras tecnologias e abordagens para construções de APIs. Embora diversas alternativas (principalmente SOAP) ainda sejam (muito) encontradas nas empresas, os precursores do movimento de APIs são definitivamente contra as demais alternativas e adotaram REST como padrão e JSON como formato de mensagens.
Lensmar também aponta as razões que ele acredita que tornaram REST uma abordagem mais bem sucedida do que outras alternativas, como por exemplo SOAP e XML-RPC. Contudo, Ole acredita que exista uma série de áreas onde o REST não funcione bem, abrindo espaço para outras abordagem. Entre elas:
- APIs assíncronas: "A necessidade de consultar dados de forma assíncrona em contraponto a abordagem tradicional de request/response nem sempre se encaixa em um design RESTful. Além disto, tecnologias como WebSockets, MQTT, AMQP, Stomp, pubsubhubbub/WebHooks são distintas ao HTTP e muitas vezes não se alinham aos princípios REST."
- Orquestração de APIs: "A granularidade oferecida por uma API REST tradicional nem sempre é uma vantagem; extrair recursos em um dashboard mobile ou em uma aplicação web complexa pode exigir muitas requisições a API, fato que adiciona overhead a lógica do cliente, aumenta o consumo de largura de banda e processamento do servidor".
- SDKs vs APIs: "Grande parte dos consumidores de uma API, fundamentalmente realizam este consumo através de uma linguagem de alto nível; javascript, python, ruby, java, etc. Este fato levou muitos provedores de API, como Google e Facebook, a disponibilizarem bibliotecas para estas linguagens. Uma vez que estas linguagens sejam em sua maioria orientadas a RPC, provavelmente as suas APIs expostas através de uma SDK também sejam fornecidas neste paradigma. Este fato, abre caminho para que a API de backend seja também RPC, ou pelo uso de protocolos binários mais otimizados ou pelo uso do recursos HTTP de forma análoga ao modelo RPC (como exemplo JSON-RPC). "
- Protocolos Binários: "[...] para transferência de mensagens otimizadas, como exemplo as utilizadas por dispositivos IoT e SDKs, diversos protocolos binários tem ganho mais atenção e uso, como por exemplo Apache Thrift, Google Protocol Buffers e Apache Avro. É importante notar que diversas tecnologias assíncronas mencionadas acima utilizam um formato binário - devido as restrições de largura de banda e processamento impostas por seus serviços e ambiente."
Ole usa como exemplo o Evernote, que utilizou o Thrift como protocolo devido as requisitos de tempo-real (cenário no qual Ole provavelmente acredita estar além da capacidade de REST). Como o autor menciona, referindo-se a um artigo escrito por Daniel Jacobson, Evernote's RESTless design:
[...] Uma API REST é provavelmente uma boa alternativa quando o público alvo é um amplo e diverso número de desenvolvedores. Mas em cenários onde a API é projetada para usuários, mercados, indústrias ou tecnologias restritas, o uso de uma solução mais específica não se trata somente de uma alternativa, mas sim, pode levar a diversas vantagens competitivas relacionadas a performance, facilidade de uso e segurança.
Ole conclui admitindo que não existe solução ideal para todos problemas, especialmente no design de APIs. "Felizmente para os apaixonados por tecnologia, o que nos motiva é o aprendizado e a aplicação de novas tecnologias para trazer o maior retorno aos stakeholders. Então, eu não sou contra esta diversidade, ela até é bem vinda". Contudo, embora alguns leitores concordaram com Ole, muitos outros discordaram desta opinião. Como exemplo John Sheehan:
Não acredito que o Evernote tenha abandonado o REST. Desde o início ele nunca foi utilizado e por razões compreensíveis. Além disto, webhooks podem ser 'REST' (ao menos no conceito popular de REST). As ressalvas listadas na seção de APIs Assíncronas não são aplicáveis na maior parte das implementações.
E Darrel Miller tenta diferenciar entre REST e o "pop REST" (termo cunhado pelo autor)
Pelo meu entendimento em relação a camada de orquestração descrita pelo Daniel Jacobson é análoga a maneira que tenho trabalhado durante anos na construção de APIs RESTFUL (guiadas por hipermedia). Só porque recentemente temos visto muitas APIS "pop REST" não significa que algo tenha mudado em relação as propriedades do REST proposto por Fielding.
De fato, grande parte das pessoas que comentaram o texto de Ole, acreditam que o autor não diferenciou muito bem APIs que seguem os princípios RESTFul de implementações que se auto denominam REST mas não seguem os princípios de Fielding. O que você acha? REST é realmente aplicável as áreas que Ole destacou? Se não, que alternativas você recomenda?