Prós e contras da arquitetura RESTful [fechado]

A discussão mais comum que eu vi sobre os prós e contras do REST tende a enquadrar essa discussão em relação ao SOAP. Eu também não tenho experiência. Atualmente, estou diante de uma decisão que minha falta de experiência está dificultando a avaliação. Estou começando a desenvolver um aplicativo que possui vários componentes - principalmente um aspecto administrativo que permite ao proprietário administrar vários sites - e uma interface de usuário voltada ao público que permite ao usuário interagir com os dados mantidos no host. Preciso avaliar as implicações de permitir que a última parte seja hospedada em qualquer lugar e se comunicar com a primeira por meio de uma arquitetura RESTful - ou exigir que os dois componentes residam no mesmo host. Quais são as principais implicações do desenvolvimento da arquitetura RESTful, principalmente no que diz respeito à sua capacidade nas seguintes áreas:

1: Segurança 2: Desempenho 3: Complexidade da interface

EDIT: Olhando para algumas das respostas a esta pergunta - devo esclarecer. Não estou procurando uma comparação com SOAP - mas uma visão geral dos aplicativos REST versus aplicativos em que todos os componentes residem em um host. (obrigado por essas respostas!)

Dadas essas áreas, posso fornecer uma visão geral aproximada, mas não posso tirar suas conclusões para você. Existem duas áreas principais em que os dois protocolos diferem:

• Formato da mensagem
• Descoberta de serviço

O formato da mensagem é mais fácil de entender. O pacote SOAP para solicitações e respostas é bastante pesado. Há o envelope SOAP que contém um cabeçalho e uma seção do corpo. O cabeçalho pode ser usado por vários filtros na cadeia de solicitações para executar algum tipo de identificação, autorização etc. No entanto, o XML é caro para analisar, o que gera uma certa penalidade na escalabilidade do seu sistema. Quanto depende da camada de processamento SOAP em sua pilha.

A descoberta de serviço é onde você provavelmente terá mais contenção. O REST, por sua própria natureza, fornece pontos finais previsíveis e o conteúdo da solicitação é uma solicitação HTTP simples. O benefício é que não há custos adicionais, e os usuários finais podem adivinhar como fazer o que precisam depois de entenderem a estrutura de URL do seu site. Obviamente, pessoas ingênuas e conscientes da segurança verão isso como uma fraqueza. Afinal, com SOAP, você precisa consumir um WSDL para saber quais são os pontos de extremidade. Obviamente, com o SOAP, você recebeu todo o formato da mensagem para poder fazer ataques mais direcionados.

Dividido pelas categorias que você deu:

Segurança

Nenhuma é inerentemente mais segura que a outra. Use bons princípios de segurança:

• Criptografar comunicações
• Certifique-se de autenticar e autorizar usuários antes de processar
• Bons hábitos de codificação para evitar ataques diretos
• E essa é apenas a pequena lista.

Lembre-se de obscuridade! = Segurança.

atuação

O desempenho bruto e a escalabilidade irão para o REST devido à solicitação, seguindo protocolos HTTP simples. A maioria das pilhas SOAP usa a análise SAX (análise baseada em eventos), o que melhora muito a escalabilidade das pilhas SOAP, mas há um impacto mensurável na sobrecarga. O SOAP possui a sobrecarga normal de processamento HTTP, além da sobrecarga de análise XML. O REST apenas possui a sobrecarga do processamento HTTP.

Complexidade

Da perspectiva do sistema, o REST vence. Há menos peças móveis, uma cadeia de pedidos mais enxuta, etc. Isso significa que é mais fácil torná-lo confiável.

Da perspectiva do programador, o SOAP pode vencer se o IDE ou a estrutura que você estiver usando fornecer um bom suporte para ele. Basicamente, com o REST, cabe a você executar o trabalho de pré-processamento (autenticação / autorização / etc), enquanto no SOAP, muito disso pode ser realizado com uma cadeia de processamento conectável.

Minha preferência

Estou muito confortável com solicitações HTTP e sei como a Web funciona. Como resultado, a abordagem REST é mais preferível para mim. No entanto, sei que alguns de meus clientes não se sentem à vontade com isso. Eles leram algum artigo do setor que denunciou a segurança de REST x SOAP etc. O ponto principal é que nenhuma dessas abordagens garante segurança. Cabe a você garantir que o aplicativo seja o mais seguro possível. Obviamente, um aplicativo da web social não exige (ou deseja) tanta segurança quanto um sistema bancário ou governamental. Muitas pilhas SOAP incluem processadores que você pode conectar para fornecer alguma aparência de segurança, mas ainda é sua responsabilidade procurá-las e instalá-las.

1. Segurança: use HTTPS. Isso se aplica a ambos.
2. Performance: . O REST custa menos CPU (menos análise, empacotamento, desembrulhamento). Além disso, o armazenamento em cache com o REST é fácil.
3. Complexidade: o REST exige muito menos em termos de configuração, afinal é apenas GET / POST. O SOAP requer muito mais administração para manter (wsdl etc.), mas é um pouco mais fácil se o seu IDE suportar.

Eu acho que o SOAP é muito inchado quando você pode fazer a mesma coisa com o REST e alguns tipos de conteúdo / mímica. Além disso, o SOAP traz muita sobrecarga, devido à sua natureza de empacotamento de invólucros e ao fato de ser mais geral e não limitado ao HTTP. O SOAP é tentador de usar se o seu IDE o suporta adequadamente e você não deseja aprender HTTP. Mas, para mim, o REST é muito mais fácil de usar e muito mais amigável à web.

Atualmente, existem APIs REST muito boas para usar. Se você gosta de Java, o Jax-RS é muito legal. Para algumas pessoas, isso é como pornografia.

Eu acho que a maior vantagem do REST é romper com as arquiteturas RPC. O REST expõe recursos, não processos. Isso permite que você crie um sistema pouco vinculado, onde alterações, melhorias e até falhas de uma parte têm impacto (negativo) limitado em outras partes.

Infelizmente, um mau uso comum do REST é expor suas estruturas de dados internas (nos piores casos, é um CRUD do seu banco de dados, ugh). Isso torna muito difícil fazê-lo com segurança. O uso "correto" é expor objetos de alto nível relevantes para a parte do sistema que você está manipulando e retornar liberalmente códigos de status de erro em qualquer inconsistência.

Outra parte frequentemente negligenciada do REST é a idempotência da maioria dos verbos. Não apenas GET, mas também PUT e DELETE devem ter exatamente o mesmo resultado se aplicados uma ou várias vezes (você está livre de retornar um 404 se já tiver sido excluído ou 'sem alteração' se o cliente estiver colocando o mesmo). Isso leva a sistemas robustos e menos interdependência de interpretações exatas da semântica.

Os padrões WS- * são principalmente sobre a execução de RPC sobre SOAP / HTTP. Portanto, todo o pensamento que entrou no CORBA e no J2EE e seus predecessores passaram a fazer o mesmo tipo de coisa em XML. Isso significa coisas como declarações de tipo e contratos de serviço, troca de metadados, segurança declarativa etc. Todas essas coisas reais de "empresa". É superutilizado, mesmo na empresa, francamente.

As pessoas que criam um aplicativo da Web na Internet como você, quase certamente estariam melhor usando uma arquitetura RESTful. Quase qualquer plataforma pode consumi-lo e fazê-lo de forma simples e sem se preocupar com qual versão de qual especificação você está usando e uma infinidade de peculiaridades de conversão de tipos específicos de ferramentas, etc.

A única grande vantagem do SOAP sobre as implementações atuais do REST é que o SOAP é mais facilmente utilizado com ferramentas - a maioria dos clientes RESTful exige que eu entenda a interface e escreva algum tipo de cliente. Para o SOAP, aponto wsdl.exe e ele gera classes para mim.