Um serviço da web no estilo Netflix ou Twitter deve usar REST ou SOAP? [fechadas]

Eu implementei dois serviços REST: Twitter e Netflix. Nas duas vezes, lutei para encontrar o uso e a lógica envolvidos na decisão de expor esses serviços como REST em vez de SOAP. Espero que alguém possa me indicar o que está faltando e explicar por que o REST foi usado como a implementação de serviços para serviços como esses.

1. A implementação de um serviço REST leva infinitamente mais tempo do que a implementação de um serviço SOAP. Existem ferramentas para todas as linguagens / estruturas / plataformas modernas lerem em um WSDL e saírem classes e clientes de proxy. A implementação de um serviço REST é feita manualmente e - obtenha isso - lendo a documentação. Além disso, durante a implementação desses dois serviços, você precisa fazer "palpites" sobre o que voltará através do canal, pois não há esquema ou documento de referência real.

2. Por que escrever um serviço REST que retorna XML de qualquer maneira? A única diferença é que, com o REST, você não conhece os tipos que cada elemento / atributo representa - você está sozinho para implementá-lo e espera que um dia uma string não seja encontrada em um campo que você pensou que sempre foi um int. O SOAP define a estrutura de dados usando o WSDL, portanto, este é um acéfalo.

3. Ouvi a reclamação de que, com o SOAP, você tem a "sobrecarga" do envelope SOAP. Atualmente, precisamos realmente nos preocupar com um punhado de bytes?

4. Ouvi o argumento de que, com o REST, você pode simplesmente inserir a URL no navegador e ver os dados. Claro, se o serviço REST estiver usando autenticação simples ou sem autenticação. O serviço Netflix, por exemplo, usa OAuth, que exige que você assine e codifique antes de enviar sua solicitação.

5. Por que precisamos de um URL "legível" para cada recurso? Se estávamos usando uma ferramenta para implementar o serviço, realmente nos preocupamos com o URL real?

Um canário em uma mina de carvão.

Estou esperando por uma pergunta como essa há quase um ano. Era inevitável que esse dia chegasse e tenho certeza de que vamos ver muitas outras perguntas como essa nos próximos meses.

Os sinais de alerta

Você está absolutamente correto, leva mais tempo para construir clientes RESTful do que clientes SOAP. Os kits de ferramentas SOAP retiram muito código padrão e disponibilizam objetos de proxy do cliente sem quase nenhum esforço. Com uma ferramenta como o Visual Studio e uma URL de servidor, posso acessar objetos remotos de complexidade arbitrária, localmente em menos de cinco minutos.

Os serviços que retornam application / xml e application / json são muito irritantes para os desenvolvedores de clientes. O que devemos fazer com esse blob de dados?

Felizmente, muitos sites que fornecem serviços REST também fornecem várias bibliotecas clientes, para que possamos usá-las para obter acesso a vários objetos fortemente tipados. Parece meio idiota. Se eles tivessem usado o SOAP, poderíamos ter codificado essas classes de proxy.

Sobrecarga de sabão, ha. É a latência que mata. Se as pessoas estão realmente preocupadas com o número de bytes em excesso que atravessam a conexão, talvez o HTTP não seja a escolha certa. Você viu quantos bytes são usados ​​pelo cabeçalho do agente do usuário?

Sim, você já tentou usar um navegador da Web como ferramenta de depuração para algo diferente de HTML e javascript. Confie em mim, é uma merda. Você pode usar apenas dois dos verbos, o cache está constantemente atrapalhando, o tratamento de erros engole tanta informação, está constantemente procurando um maldito favicon.ico. Apenas atire em mim.

URL legível. Apenas substantivos, sem verbos. Sim, isso é fácil, desde que façamos apenas operações CRUD e só precisamos acessar uma hierarquia de objetos de uma maneira. Infelizmente, a maioria dos aplicativos precisa de um pouquinho mais de funcionalidade do que isso.

O desastre iminente

Atualmente, há um grande número de métricas de desenvolvedores que desenvolvem aplicativos que se integram aos serviços REST que estão no processo de chegar ao mesmo conjunto de conclusões que você possui. Eles prometeram simplicidade, flexibilidade, escalabilidade, evolução e o santo graal da reutilização acidental. As características da web em si, como as coisas podem dar errado.

No entanto, eles estão descobrindo que o controle de versão é um problema, mas o compilador não ajuda a detectar problemas. O código do cliente escrito à mão é uma tarefa difícil de manter à medida que as estruturas de dados evoluem e os URLs são refatorados. Projetar APIs em torno de apenas substantivos e quatro verbos pode ser muito difícil, especialmente com os fanáticos do URL RESTful informando quando você pode e não pode usar as strings de consulta.

Os desenvolvedores começarão a perguntar por que estamos desperdiçando nosso esforço no suporte aos formatos Json e Xml, por que não concentrar nossos esforços em apenas um e fazê-lo bem?

Como as coisas deram tão errado

Vou te contar o que deu errado. Nós, como desenvolvedores, deixamos os departamentos de marketing aproveitarem nossa principal fraqueza. Nossa eterna busca pela bala de prata nos cegou para a realidade do que realmente é o REST. Na superfície, o REST parece tão fácil e simples. Nomeie seus recursos com URLs e use GET, PUT, POST e DELETE. Inferno, nós, os desenvolvedores, já sabemos como fazer isso, estamos lidando com bancos de dados há anos que possuem tabelas e colunas e instruções SQL que possuem SELECT, INSERT, UPDATE e DELETE. Deveria ter sido um pedaço de bolo.

Existem outras partes do REST que algumas pessoas discutem, como auto-descrição e restrição de hipermídia, mas essas restrições não são tão simples quanto a identificação de recursos e a interface uniforme. O parece adicionar complexidade onde o objetivo desejado é a simplicidade.

Essa versão diluída do REST foi validada na cultura do desenvolvedor de várias maneiras. Foram criadas estruturas de servidor que incentivavam a identificação de recursos e a interface uniforme, mas não faziam nada para suportar as outras restrições. Os termos começaram a flutuar em torno da diferenciação das abordagens (HI-REST x LO-REST, REST corporativo vs REST acadêmico, REST x RESTful).

Algumas pessoas gritam que, se você não aplicar todas as restrições, não será REST. Você não receberá os benefícios. Não há metade do REST. Mas essas vozes foram rotuladas como fanáticos religiosos que ficaram chateados com o fato de seu precioso termo ter sido roubado da obscuridade e tornado popular. Pessoas ciumentas que tentam fazer com que o REST pareça mais difícil do que é.

REST, o termo, definitivamente se tornou popular. Quase todas as principais propriedades da web que possuem uma API oferecem suporte a "REST". Twitter e Netflix são dois de alto perfil. O mais assustador é que só consigo pensar em uma API pública que seja auto-descritiva e há algumas que realmente implementam a restrição hipermídia. Certamente, alguns sites como o StackOverflow e o Gowalla suportam links em suas respostas, mas existem muitos buracos nos links. A API StackOverflow não possui página raiz. Imagine o sucesso do site se não houvesse uma página inicial para o site!

Você foi enganado, eu tenho medo

Se você chegou até aqui, a resposta curta para sua pergunta é que as APIs (Netflix e Twitter) não estão em conformidade com todas as restrições e, portanto, você não obterá os benefícios que as APIs REST devem trazer.

Os clientes REST demoram mais para serem construídos do que os clientes SOAP, mas não estão vinculados a um serviço específico, portanto, você poderá reutilizá-los entre os serviços. Tomemos o exemplo clássico de um navegador da web. Quantos serviços um navegador da web pode acessar? Que tal um leitor de feeds? Agora, quantos serviços diferentes o cliente médio do Twitter pode acessar? Sim, apenas um.

Os clientes REST não devem ser criados para interagir com um único serviço, eles devem ser criados para lidar com tipos de mídia específicos que poderiam ser atendidos por qualquer serviço. A questão óbvia é: como você pode construir um cliente REST para um serviço que entrega application / json ou application / xml. Bem, você não pode. Isso ocorre porque esses formatos são completamente inúteis para um cliente REST. Você mesmo disse,

você precisa fazer "palpites" sobre o que voltará ao canal, pois não há um esquema ou documento de referência real

Você está absolutamente correto para serviços como o Twitter. No entanto, a restrição auto-descritiva no REST diz que o cabeçalho do tipo de conteúdo HTTP deve descrever exatamente o conteúdo que está sendo transmitido pela conexão. Entregar application / json e application / xml não diz nada sobre o conteúdo.

Quando se trata de considerar o desempenho de sistemas baseados em REST, é necessário ter uma visão geral. Falar sobre bytes de envelope é como falar sobre desenrolamento de loop ao comparar uma classificação rápida a uma classificação de shell. Há cenários em que o SOAP pode ter um desempenho melhor e há cenários em que o REST pode ter um desempenho melhor. Contexto é tudo.

O REST obtém grande parte de sua vantagem de desempenho por ser muito flexível sobre os tipos de mídia suportados e por ter um suporte sofisticado para armazenamento em cache. Para que o cache funcione bem, embora quase todas as restrições devam ser respeitadas.

Seu último argumento sobre URLs legíveis é de longe o mais irônico. Se você realmente se comprometer com a restrição de hipermídia, cada URL poderá ser um GUID e o desenvolvedor do cliente não perderá nada na legibilidade.

O fato de os URIs serem opacos para o cliente é uma das coisas mais importantes ao desenvolver sistemas REST. URLs legíveis são convenientes para o desenvolvedor do servidor e URLs bem estruturados facilitam o envio da solicitação pela estrutura do servidor, mas esses são detalhes de implementação que não devem ter impacto nos desenvolvedores que consomem a API.

A API do Twitter não está nem perto de ser RESTful e é por isso que você não consegue ver nenhum benefício em usá-la no SOAP. A API da Netflix está muito mais próxima, mas o uso de tipos de mídia genéricos demonstra que a falta de adesão a uma única restrição pode ter um impacto profundo nos benefícios derivados do serviço.

Pode não ser tudo culpa deles

Fiz bastante despejo nos provedores de serviços, mas são necessários dois para dançar RESTfully. Um serviço pode seguir todas as restrições religiosamente e um cliente ainda pode desfazer facilmente todos os benefícios.

Se um cliente codifica os URLs para acessar determinados tipos de recursos, isso impede o servidor de alterar esses URLs. Qualquer tipo de construção de URL com base no conhecimento implícito de como o serviço estrutura seus URLs é uma violação.

Fazer suposições sobre que tipo de representação será retornado de um link pode levar a problemas. Fazer suposições sobre o conteúdo da representação com base no conhecimento que não é explicitamente declarado nos cabeçalhos HTTP definitivamente criará um acoplamento que causará problemas no futuro.

Eles deveriam ter usado SOAP?

Pessoalmente, acho que não. O REST feito corretamente permite que um sistema distribuído evolua a longo prazo. Se você estiver construindo sistemas distribuídos que possuem componentes desenvolvidos por pessoas diferentes e precisam durar muitos anos, o REST é uma opção muito boa.

SOAP é uma orientada a objetos , chamada de procedimento remoto tecnologia de pilha. Ele funciona criando uma nova abstração em cima de um protocolo existente (HTTP).

O REST é uma abordagem orientada a documentos , que simplesmente usa os recursos de um protocolo existente (HTTP). "REST" é apenas uma palavra da moda - o conceito é este: basta usar a web da maneira como foi projetada para funcionar!

Em resposta às edições da pergunta:

1. "A implementação de um serviço REST leva infinitamente mais tempo do que a implementação de um serviço SOAP."

   Hum, não, não pode ser infinitamente mais longo. E nos casos em que o que você está tentando recuperar já é um documento ou arquivo , na verdade é muito mais rápido . Por exemplo, a especificação OGC para WMS (Web Mapping Service) define uma versão SOAP e REST do protocolo, e há uma razão pela qual quase ninguém implementa a versão SOAP - é porque se você está tentando obter um mapa, é É muito mais fácil criar uma URL e buscar bytes de imagem a partir dessa URL do que se preocupar em encapsulá-lo em uma mensagem SOAP. Mas sim, concordarei que, se o objetivo do serviço da Web for transferir algum objeto fortemente digitado em um modelo de objeto de domínio, o SOAP será mais adequado para esse uso.

2. "Por que escrever um serviço REST que retorna XML de qualquer maneira?"

   Bem, sim, isso pode ser bobo. Mas isso depende do que é o XML. Se houver um esquema claramente definido para ele em algum lugar, não haverá ambiguidade. Por exemplo, você pode pensar nos URLs WSDL como um tipo de serviço da web RESTful para recuperar informações sobre um serviço da web. Nesse caso, adicionar a sobrecarga de outra solicitação SOAP não faria sentido.

   Em geral, o REST vence quando o conteúdo que está sendo transferido pode ser considerado como um arquivo, como uma única unidade . SOAP vence quando o conteúdo precisa ser tratado como um objeto com membros .

3. "Ouvi a reclamação de que, com o SOAP, você tem a" sobrecarga "do envelope SOAP. Hoje em dia, realmente precisamos nos preocupar com um punhado de bytes?"

   Sim. Nem em todas as circunstâncias, mas existem sites com muito tráfego onde isso faz a diferença. É suficiente diferença para compensar as diferenças semânticas do uso de SOAP em vez de REST? Eu duvido. Se você estiver executando um protocolo de comunicação remota de objetos e o número de bytes estiver fazendo diferença, o SOAP provavelmente não será a ferramenta para você - talvez você deva usar CORBA ou DCOM.

4. "Ouvi o argumento de que, com o REST, você pode simplesmente inserir a URL no navegador e ver os dados".

   Sim, e esse é um grande argumento a favor do REST, se fizer sentido exibir os dados em um navegador . Por exemplo, com dados de imagem, é uma maneira fácil de depurar o serviço - basta colar o URL na barra de endereços do navegador e ver como é a imagem. Ou se os dados retornados estiverem em XML e você tiver uma folha de estilo XML referenciada que renderiza HTML legível no navegador, você obtém o benefício da marcação semântica e da fácil visualização em um único pacote. Mas você está certo, esse benefício evapora principalmente ao trabalhar com esquemas de autenticação mais complexos. Se você não pode codificar todas as suas informações de autenticação em cada solicitação HTTP , eu diria que elas não contam como REST.

5. "Por que precisamos de um URL" legível "para cada recurso? Se estávamos usando uma ferramenta para implementar o serviço, realmente nos preocupamos com o URL real?"

   Bem, isto depende. Por que precisamos de URLs legíveis para qualquer recurso na Web? Você pode ler o ensaio de Tim Berners-Lee Os URIs legais não mudam para a justificativa, mas basicamente, desde que o recurso ainda possa ser útil no futuro, o URI desse recurso deve permanecer o mesmo.

   Obviamente, para recursos transitórios (como o link "Dinheiro de hoje" no ensaio), não há necessidade, pois a necessidade de referenciar o recurso desaparece se o recurso correspondente desaparecer. Mas, para recursos mais permanentes (como perguntas sobre o StackOverflow, por exemplo, ou filmes no IMDB), você deseja ter um URL que funcione para sempre. Ao projetar um serviço da Web, você precisa decidir se os próprios recursos podem sobreviver ao seu serviço e, nesse caso, o REST provavelmente é o caminho certo a seguir.

Para o registro, sim, eu tenho desenvolvido páginas da Web desde muito antes da existência do NetFlix ou Twitter. E não, ainda não tive nenhuma necessidade ou oportunidade de implementar um cliente para os serviços NetFlix ou Twitter. Mas, mesmo que seus serviços sejam atrozmente difíceis de trabalhar, isso não significa que a tecnologia em que eles implementaram seus serviços seja ruim - apenas que essas duas implementações são ruins.

Para resumir uma longa história: REST e SOAP são apenas ferramentas . Cada um deles tem pontos fortes e fracos. Se a única ferramenta que você possui é um martelo, todo problema parece um prego. Portanto, conheça as duas ferramentas, aprenda como usá-las corretamente e escolha a ferramenta certa para cada trabalho.

Uma pergunta honesta merece uma resposta honesta. Mas primeiro, por que você usou o texto desta pergunta como resposta a outra pergunta se não achou que era de natureza retórica?

De qualquer forma:

1. " Existem ferramentas para todas as linguagens / estruturas / plataformas modernas lerem em um WSDL e gerarem classes e clientes proxy de saída. A implementação de um serviço REST é feita manualmente, lendo a documentação. "

   Assim como os fornecedores de navegadores leram e releram a especificação HTML 4.01 para cima e para baixo para tentar implementar uma experiência de navegação consistente. Você refletiu sobre o fato de que os navegadores foram inventados muito antes do Internet banking e do stackoverflow e, no entanto, você pode usar um navegador para fazer exatamente essas coisas. Isso é possível devido ao único motivo de todos concordarem em usar HTML (e formatos relacionados, como CSS, JS, JPEG, etc.).

   Os blogs não são tão novos assim, e alguém criou o AtomPub, que permite que qualquer software de blog acesse e atualize postagens em um blog, assim como qualquer navegador da web pode acessar qualquer página da web. Isso é bem legal e funciona por causa das restrições RESTful impostas pelo protocolo.

   Mas para o Twitter e a Netflix, não há um acordo universal de que "todos os microblogs existentes devem usar o tipo de mídia application / tweet", principalmente porque o microblog é muito novo. Talvez em alguns anos alguns serviços de microblog se estabeleçam na mesma API para que Twitter, Facebook, Identica e possam interoperar. Nenhuma de suas APIs existentes está perto do RESTful, por mais que reivindiquem, então não espero que isso aconteça em breve.

   " Além disso, ao implementar esses dois serviços, você precisa fazer" palpites "sobre o que voltará ao canal, pois não há um esquema real ou documento de referência " .

   Você acertou a unha na cabeça. O REST tem tudo a ver com distribuição e hipermídia, e isso resume tudo. Um navegador analisa o que é obtido de uma solicitação e mostra para o usuário. Uma página HTML geralmente gera muito mais solicitações GET, por exemplo, CSS, scripts e imagens. Normalmente, uma imagem é renderizada na tela, o JavaScript é executado e assim por diante. Cada vez, o navegador faz o que faz porque encontrou o link em uma tag <img>ou <style>e o tipo de mídia de resposta foi image/jpegoutext/css .

   Se o Twitter criar uma API baseada em hipermídia, provavelmente sempre retornará uma application/tweetvez que você seguir um link para um tweet, mas o cliente nunca deve assumi-lo e sempre verificar o que obtém antes de agir nele.

2. " Por que escrever um serviço REST que retorna XML de qualquer maneira? "

   Tudo isso se resume a tipos de mídia. Como o HTML, se você vir um elemento que não tem idéia do que realmente significa, a especificação do HTML instrui-o a ignorá-lo e a processar o "corpo" da tag, se houver. Da mesma forma, a especificação do átomo instrui você a ignorar elementos desconhecidos e marcação externa (de diferentes espaços para nome) e não processar o corpo (IIRC).

   A criação de tipos de mídia para domínios de problemas genéricos (como no tipo de mídia HTML para o domínio de problemas de rich text ) é muito difícil. Tornar tipos de mídia para domínios com problemas muito estreitos é provavelmente muito mais fácil (como um tweet). Mas é sempre uma boa idéia projetar para extensibilidade e especificar como os clientes (e servidores) devem reagir quando virem elementos ou itens de dados que não correspondem à especificação. O JPEG, por exemplo, possui um tipo de registro específico do aplicativo (por exemplo, APP1) que é usado para conter todos os tipos de metadados.

3. " Ouvi a reclamação de que, com o SOAP, você tem a" sobrecarga "do envelope SOAP. Nos dias de hoje, realmente precisamos nos preocupar com um punhado de bytes? "

   Não, nós não. O REST não é absolutamente eficiente em relação à conexão, mas na verdade está trocando a eficiência da conexão. A eficiência do REST vem das possibilidades de armazenamento em cache ativadas por todas as outras restrições: Notas da dissertação de Fielding : A desvantagem, no entanto, é que uma interface uniforme degrada eficiência, já que as informações são transferidas de forma padronizada e não específica para as necessidades de um aplicativo. A interface REST foi projetada para ser eficiente para a transferência de dados hipermídia de alta granularidade, otimizando para o caso comum da Web, mas resultando em uma interface que não é ideal para outras formas de interação arquitetural. Não acho que a sobrecarga de contagem de bytes do SOAP Envelope seja uma preocupação válida.

4. " Ouvi o argumento de que, com o REST, você pode simplesmente inserir a URL no navegador e ver os dados " .

   Sim, esse também é um argumento inválido. Não é assim que funciona. Mesmo que funcionasse, o mais restrito APIs REST usam tipos de mídia dos quais os navegadores não têm idéia e ainda não funcionam.

   Mas há muito mais possibilidades do que um navegador para testar uma API baseada em HTTP, como utilitários de linha de comando ou extensões de navegador que permitem controlar quase qualquer aspecto de uma solicitação HTTP, inspecionar cabeçalhos de resposta e descobrir links para você seguir. Mas, mesmo assim, isso não é tão fácil quanto gerar stubs WSDL e criar um programa de três linhas para chamar a função de qualquer maneira.

5. " Por que precisamos de um URL" legível "para cada recurso? Se estávamos usando uma ferramenta para implementar o serviço, realmente nos preocupamos com o URL real? "

   Se você observar como a Web funciona, tenho certeza de que os humanos estão satisfeitos com o fato de o URI de uma página da Wikipédia ter esta aparência, em http://en.wikipedia.org/wiki/Stack_overflowvez de http://en.wikipedia.org/wiki/?oldid=376349090. Mas, na verdade, não é importante para o REST. O importante é tentar colocar os dados relevantes no URI que provavelmente não serão alterados. Você pode pensar que o ID do banco de dados nunca será alterado, mas o que acontece quando dois conjuntos de dados precisam ser mesclados? Todas as suas chaves primárias mudam. O título da página (Stack_overflow) não será alterado.

Desculpe pela resposta longa, mas acredito que esta pergunta é válida e não foi abordada antes aqui no SO. Tenho certeza que Darrel Miller irá adicionar sua resposta quando voltar também.

Editar: formatação

Martin Fowler tem um post sobre o Richardson Maturity Model, que faz um ótimo trabalho explicando a diferença entre SOAP e REST.

O WSDL e outros protocolos no nível do documento são redundantes. O protocolo HTTP suporta um conjunto de operações muito mais rico, além de apenas servir documentos e enviar formulários.

Os apoiadores do REST não se sentem à vontade com essa redundância.