Quase uma década atrás, houve uma grande agitação em torno dos sistemas baseados em REST e SOAP. Vários autores escreveram sobre os prós e os contras de um ou outro, ou quando você deveria considerar usar um em vez do outro. No entanto, com a atenção passando dos Web Services baseados em SOAP para o REST e HTTP, os argumentos e discussões diminuíram e muitos praticantes do SOA adotaram o REST (ou HTTP simples) como base para seus sistemas distribuídos. No entanto, recentemente, Pakal De Bonchamp escreveu um artigo chamado "REST é o novo SOAP", no qual ele compara o uso de REST com "um testemunho de insanidade".
Seu artigo é longo e detalhado, mas alguns dos pontos-chave que ele destaca incluem a complexidade, em sua opinião, de simplesmente expor uma API, o que poderia ser feito através de um mecanismo RPC em "algumas horas", mas que com o REST pode levar muito mais tempo pois:
Não há mais padrões, não há mais especificações precisas. Apenas uma vaga "filosofia RESTfull", propensa a infinitos debates metafísicos e igualmente tantas soluções alternativas.
O mapeamento dos métodos para as operações CRUD não é direto. Como você determina se e quando criar novas instâncias de recurso em vez de reutilizar um recurso existente? Os códigos de erro HTTP são limitados, em sua opinião, e impõem problemas ao tentar expressar situações de erro mais ricas. E a lista continua. O resultado final?
Você perdeu horas reinventando a roda. Nem sequer uma roda inteligente e personalizada, mas uma roda quebrada e frágil, que requer toneladas de documentação para ser entendida; e violando especificações sem sequer saber disso.
Ele se aprofunda em vários detalhes de verbos HTTP específicos, incluindo o PUT, e os raramente raramente discutidos PATCH e DELETE:
Você quer usar o PUT para atualizar seu recurso? OK, mas algumas "especificações sagradas" indicam que a entrada de dados deve ser equivalente à representação recebida através de um GET. Então, o que você faz com os inúmeros parâmetros somente-leitura retornados pelo GET (tempo de criação, último tempo de atualização, token gerado pelo servidor...)? Você os omite e viola os princípios do PUT? Você os inclui de qualquer maneira e espera um "Conflito HTTP 409" se eles não combinarem com os valores do lado do servidor (forçando você a emitir um GET...)? Você passa valores aleatórios e espera que os servidores os ignorem (a alegria dos erros silenciosos)? Escolha o seu veneno, o REST claramente não tem ideia do que é um atributo somente de leitura, e isso não será corrigido em breve. Enquanto isso, um GET deveria perigosamente retornar a senha (ou o número do cartão de crédito) que foi enviada em um POST / PUT anterior. Boa sorte também para lidar com esses parâmetros somente de gravação. Eu esqueci de mencionar que o PUT também traz condições de concorrência perigosas, onde vários clientes irão substituir as mudanças um do outro, enquanto eles só queriam atualizar diferentes campos?
O tratamento de erros, os conceitos arquiteturais do REST, e muitos outros aspectos recebem uma revisão detalhada e não vão bem. Para os apoiadores do REST e aqueles que não estão convencidos, vale a pena ler o artigo. Ele conclui com o seguinte:
A chamada remota de uma procedure de forma quase transparente era o que 99% de pessoas realmente precisavam, e os protocolos existentes, tão imperfeitos quanto eram, faziam o trabalho bem. Esta tremenda monomania para o menor denominador comum da web, HTTP, resultou principalmente em um enorme desperdício de tempo. O REST prometeu simplicidade e entregou complexidade.
O REST prometeu robustez e entregou fragilidade.
O REST prometeu interoperabilidade e entregou heterogeneidade.
O REST é o novo SOAP.
Ao ler os muitos comentários sobre o artigo, fica claro que algumas pessoas concordam com ele, mas a maioria discorda, apontando inúmeras falhas em seu argumento. Por exemplo, Filippos Vasilakis comenta:
Talvez você deva dar uma olhada na tese do Roy. O que você está atacando aqui é a comum ideia errada que se tem sobre o REST. Como Roy observou em sua tese, o REST talvez não sirva a todos os casos, mas se encaixa muito bem no caso em que você não pode controlar o cliente. Então, se você conhece algum outro modelo que seja auto-descritivo e assim, evolutivo, avise-nos, pois esse é o objetivo do REST. Falar com dispositivos/ clientes/ hardware que não podemos controlar (como o aplicativo para dispositivos móveis na loja Apple, que precisa de 10 dias para implantar uma nova alteração, se sua atualização não for rejeitada pela Apple, dispositivos de sensor que você sequer acessa / atualiza, etc). Para esses cenários, temos o REST e, em seguida, vem o GraphQL com muitas limitações e problemas. Mas se você apresentar outro modelo que resolva a questão da evolutividade, por favor nos informe. O RPC não é um deles.
Outro comentário, desta vez de Vlad Ko:
Nossa! O que eu acabei de ler? Você está se queixando de dedicar seu tempo para arquitetar uma API decente? Eu acredito que é sua responsabilidade e um objetivo como desenvolvedor garantir isso. Queixar-se de todos os problemas relacionados ou não ao REST não tem sentido, e é infantil. Cada linguagem, protocolo, especificação, e conceito tem problemas, erros, sintaxe ilógica, VMs lentas, falta de tipo, é rígido, muito solto, muito funcional, não OOP suficiente. Bem-vindo ao mundo da engenharia de software.
And from Christopher Patti:
E um comentário de Christopher Patti:
Este artigo é excelente. Ele é um balde de água fria, mas faz o seu caso de forma detalhada, bem fundamentada, e com muita evidência de apoio. Mas, há um fator que você não discute: ferramentas. As pessoas desistiram do paradigma da pureza lógica que o SOAP é, ou era, se seu artigo estiver correto, porque se você não estava trabalhando em Java ou .NET, o ferramental era realmente, 'realmente' horrível. Disseram-me que melhorou, mas quando as pessoas sentem dor, elas reagem a essa dor adotando novas ferramentas. Entendo que sua tese defenda que possamos ter escolhido um caminho infeliz e devemos seguir em frente, mas para quê? Você cita outros protocolos mais modernos, mas eu estou curioso sobre exemplos específicos que você pode citar que poderiam funcionar como uma substituição direta para SOAP ou REST.
Além dos comentários, o artigo original promoveu muita atividade em várias plataformas de redes sociais. Eventualmente, Phil Sturgeon, engenheiro de plataforma da WeWork, escreveu um artigo chamado simplesmente "Resposta ao artigo REST é o novo SOAP" porque, aparentemente, muitas pessoas pediram que ele respondesse às reivindicações feitas no artigo original.
O artigo inteiro está cheio de mal-entendidos comuns sobre REST e HTTP. Apesar de dedicar minha carreira a tentar educar as pessoas quanto a essas confusões, elas continuam sendo abundantes. Claramente, não estou sendo gritado o suficiente, escrevendo o bastante, ou fazendo um trabalho bastante bom. Essa é a frustração que você pode ouvir na minha escrita, mas nada é direcionado ao autor.
Tal como acontece com o artigo inicial, esta resposta é longa e Phil disseca os problemas com REST que Pakal havia discutido em muitos detalhes. Por exemplo, sobre a referência de Pakal a construção de "uma roda quebrada e frágil", Phil diz:
Ok, isso é frustrante. As APIs REST são muitas vezes ridicularizadas porque os proponentes dizem que você não deve precisar de documentação. Uma API REST absolutamente não deveria precisar de documentação, mas eu passei os últimos meses trabalhando na geração de documentação para nossas APIs, porque elas são todas as APIs RPC. Quando uma API representa seu próprio estado, usa hipermídia para declarar seus recursos, e fornece um contrato, você pode optar por gerar documentação legível para humanos, mas ela só serve para as pessoas que tratam a API REST como uma API RPC... Uma API REST de forma bastante definitiva requer menos documentação, a menos que você tenha construído apenas um RPC não especificado que está fingindo ser REST, como tantas pessoas fazem.
Quanto a discussão de Pakal sobre os perigos do PUT, e etc, "Isso parece uma frustração nascida do não entendimento do propósito de PUT". A análise e as respostas de Phil continuam. Na verdade, mesmo sem ler o artigo original, a resposta de Phil vale a pena ler por seus próprios méritos. Mas o tópico subjacente geral é que muito, se não todas, as queixas de Pakal sobre o REST são devido a seus mal-entendidos. Phil conclui com:
Eu entendo, REST é um tópico complexo. Muitas pessoas pensam que entendem, e são falsamente validadas quando topam com outras pessoas que não entendem do assunto. Em todos os lugares as pessoas estão criando APIs tipo-REST que são basicamente apenas verbos RPC + HTTP + URLs bonitas, e como isso não parece muito útil eles escrevem artigos gigantescos explicando por que isso não é muito útil...
E esse deve ter sido o caso. No entanto, parece que Phil e Pakal continuaram a ter discussões e Phil escreveu uma nova atualização.
Ainda estou tendo um diálogo produtivo com o autor, ajudando-o a entender como o REST funciona. Acho que isso poderia interessar alguns de vocês também.
Espero que o leitor interessado acompanhe como a conversa está evoluindo.