Convencer um cliente a oferecer um serviço da Web RESTful em vez de um serviço SOAP? [fechadas]

4

ANTECEDENTES:

Eu desenvolvo plugins WordPress personalizados para meus clientes que eles distribuem através do repositório de plugins do WordPress . Estou cada vez mais correndo em clientes que querem meus plugins WordPress para consumir serviços web SOAP desenvolvidos por suas equipes de desenvolvimento interno (e como um aparte, até agora, cada um desses serviços web SOAP foram desenvolvidos usando o asp.net).

Da minha experiência, especialmente no domínio do desenvolvimento de plugins do WordPress, a interação com serviços Web RESTful é quase sempre trivial e eles simplesmente funcionam. Do meu conhecimento reconhecidamente de terceira mão de realmente consumir serviços web SOAP através de plugins WordPress, especialmente aqueles que são amplamente distribuídos para usuários não-técnicos WordPress, incorporar um cliente SOAP é cheio de perigos, pois há tantas coisas que podem causar um SOAP chamada de serviço da web para falhar; pilha SOAP local errada, falta de pilha SOAP local, resposta de serviço malformada, etc. etc.

O que estou descobrindo é que muitas pessoas de negócios em posições de tomada de decisão dentro dos meus clientes (prospectivos) têm pouco ou nenhum conhecimento das diferenças tangíveis entre serviços Web RESTful e SOAP. serviços web baseados Para essas pessoas, um serviço da web é um serviço da web; São 6 de um, meia dúzia do outro. Eles tendem a pensar "O que há com todo o barulho?"

Além disso, os desenvolvedores do ASP.NET nesses clientes, desenvolvedores que foram imersos no conjunto de ferramentas do Visual Studio, foram condicionados pelo excelente marketing de ferramentas para desenvolvedores da Microsoft para ver o SOAP como o caminho mais fácil; Basta adicionar o Visual Studio e o serviço da Web SOAP funciona como mágica! E isso acontece, pelo menos até você tentar usar alguma outra pilha para acessar o serviço da Web e / ou até tentar obter pessoas que não estejam usando o Visual Studio ou adotar o serviço da Web; então a imagem é bem diferente.

Quando esses desenvolvedores me ouvem dizer que eles implementam um serviço web RESTful, em vez disso, se eu for empurrado para trás, recebo uma de duas respostas; eles dizem:

  1. "Por que ir para todo o esforço de criar um serviço web RESTful quando eu já criei um serviço web SOAP para você usar? Você está apenas criando mais trabalho para mim e eu tenho outras coisas fazer. "

  2. "Não há nenhum benefício para serviços web RESTful; SOAP é realmente muito melhor porque eu posso criar um objeto e então posso programá-lo como um objeto. Além disso, o SOAP é usado por desenvolvedores corporativos e nós são uma loja de desenvolvimento empresarial; o REST não é apenas para uso sério. "

Como um aparte, acho que uma das razões pelas quais recebo essas respostas é porque os desenvolvedores do ASP.NET geralmente têm pouca ou nenhuma exposição ao REST (este artigo não é realmente uma questão para a maioria dos desenvolvedores do ASP.NET? ) Eu acho que eles realmente não sabem quão pouco trabalho é necessário para criar um serviço web RESTful HTTP GET -apenas uma vez que eles já tenham todo o código implementado para um serviço web SOAP.

E eu acho que isso acontece porque a abordagem da Microsoft é fornecer ferramentas para os desenvolvedores, para que eles não sintam a necessidade de aprender os detalhes. Já que o Visual Studio afirma cuidar de tantas coisas para os desenvolvedores, por que um desenvolvedor deve aprender alguma coisa que o Visual Studio alega tratar? Eu sei que é o que eu pensava quando eu costumava codificar sites para a plataforma Microsoft. Foi só quando me mudei para o PHP que percebi quais eram os cabeçalhos HTTP e percebi a diferença entre um código de status HTTP 301 e 302, e o mais importante é que percebi que esses conceitos eram fáceis de entender e de vital importância para entender se alguém quiser criar um site robusto e eficaz na Web.

MINHA PERGUNTA:

O que eu estou perguntando é como eu posso contrapor essas respostas e fazer com que meus clientes em potencial considerem a criação de um serviço web RESTful? Como posso fazer com que eles vejam os muitos benefícios de usar um serviço da web RESTful? pode oferecer-lhes? Além disso, como posso fazer com que eles vejam a grande desvantagem potencial de lançar um plug-in do WordPress que potencialmente incorra em um grande custo de suporte?

NOTA:

Se você não concordar com a premissa de que chamar serviços Web RESTful é preferível a chamar serviços da Web SOAP de um plug-in do WordPress, entenda que estou pedindo ajuda de pessoas que concordam com a minha premissa e idealmente eu Não estou olhando para debater a premissa.

No entanto, se você sentir necessidade de argumentar, faça-o respeitosamente, reconhecendo que cada um de nós tem direito a nossas próprias opiniões e que talvez você nunca seja capaz de me convencer a concordar com as suas. O que, claro, deve ficar bem.

    
por MikeSchinkel 15.04.2011 / 07:17
fonte

9 respostas

15

Então, embora eu tenha a tendência de concordar com sua posição, ainda vou lançar algumas ideias para o equilíbrio. Primeiro o problema:

"Why go to all the effort of creating a RESTful web service when I've already created a SOAP web service for you to use? You are just creating more work for me and I have other things to do."

O problema é que eles já fizeram o trabalho. Mais do que provável, com base na sua descrição, esses serviços da Web são serviços WCF. A Microsoft realmente se preocupou em criar serviços da Web baseados em SOAP, portanto, a partir de uma perspectiva de desenvolvimento / manutenção, faz sentido da perspectiva do cliente apenas usar a pilha do WCF. Se eles tivessem se dado ao trabalho de testar a pilha SOAP, você não teria uma venda tão difícil.

O problema, como eu vejo, é que o Wordpress (uma tecnologia PHP) está mal equipado para lidar com o SOAP. O SOAP é uma adaptação "padrão" não padrão do protocolo HTTP. Em suma, em vez de sua solicitação típica e informações de cabeçalho HTTP como parte de um cliente normal, também existe um corpo XML. Esse XML geralmente é mapeado para objetos e possui suas próprias informações de cabeçalho. Em suma, não é algo que o PHP é projetado para fora da caixa. Você está usando o PHP: SOAP ? Espero que isso torne o uso do SOAP mais fácil.

No entanto, mais sobre estratégia prática depois.

"There is no benefit to RESTful web services; SOAP is actually much better because I can create an object and then I can program it just like an object. Plus SOAP is used by enterprise developers and we are an enterprise development shop; REST is just not for serious use."

Isso é realmente muito mais fácil de lidar. Em suma, a maioria dos serviços da web que vi têm modelos de solicitação muito simples. Tudo o que você precisa passar é um ID e algum token de autenticação. Esse é o tipo trivial de interação com o qual os serviços da Web RESTful se desenvolvem. Você pode retornar facilmente uma representação vinculada XML ou JSON do seu objeto. Na verdade, a pilha do MS possui a lógica de ligação para ambas delas. Muito raramente um cliente precisa enviar dados hierárquicos complexos para o servidor.

Formas práticas de fazer vocês dois felizes

Sei que pode parecer bobo, mas você já considerou um wrapper de serviço da web? Algo que traduza as chamadas REST necessárias para manter o Wordpress feliz nas chamadas baseadas em SOAP que tornam os serviços WCF do seu cliente felizes? Essa pode ser a maneira mais pacífica de lidar com isso. Tendo feito serviços Web RESTful usando ASP.NET MVC, seria trivial manter as coisas na pilha da Microsoft onde você precisa, e executar a tradução para a pilha PHP de uma maneira sã.

    
por 15.04.2011 / 15:07
fonte
14

Aqui está um pensamento para você: por que você não dá ao cliente o que eles pedem? Eles são, afinal de contas, seu cliente e seu primeiro ponto é extremamente válido. Por que eles deveriam fazer um trabalho extra por causa de suas dúvidas de segunda mão sobre os serviços SOAP?

Se você realmente acredita que isso aumentará sua carga de trabalho, certifique-se de que o tipo de serviço que eles fornecem esteja incluído no contrato e ofereça mais lance onde eles especificam o SOAP.

Se você provar que está certo, em vez de apenas um trollista de linguagem contra os desenvolvedores Microsoft-stack, então você terá um argumento melhor na próxima vez do que chamar seus desenvolvedores (em quem eles provavelmente confiam muito mais do que confiam. você) "gordo, mudo e feliz".

    
por 15.04.2011 / 09:16
fonte
10

Minha resposta para você é que você não pode. Não conheço seus clientes, mas pela sua descrição eles não soam como se fossem ambivalentes em sua determinação. Eles pediram que você fornecesse um serviço, então sugiro que você o forneça ou siga em frente.

Em uma nota complementar, muito do corpo de sua pergunta envolve acusações contra a Microsoft por criar programadores preguiçosos. Essa é a sua acusação de questionamento da Microsoft ou isso é relevante para os programadores que tomaram a decisão de usar o SOAP? Você está chamando-os de preguiçosos ou apenas tomando potshots em uma empresa de software? Eu suspeito que isso seja menos sobre a política de fazer com que eles usem uma tecnologia "melhor" do que sobre forçar sua zona de conforto a descer pela garganta deles. Minha sugestão para você como desenvolvedor freelancer (que é o que estou assumindo aqui) é que você precisa aprender a se adaptar aos requisitos do cliente. Recomendar soluções alternativas só é apropriado se você puder mostrar uma análise de custo / benefício tangível ou se o cliente não tiver conhecimento real do processo envolvido e estiver tomando decisões desinformadas.

Além disso, ajuda a seguir o axioma: o cliente nem sempre está certo, mas o cliente é quem paga as contas.

Nota: Eu não estou de forma alguma dizendo que você está certo ou errado. Meus comentários são simplesmente destinados a apontar o que pode ser um pensamento confuso de sua parte com relação a como o relacionamento cliente / provedor funciona. Eu também estou tentando levá-lo a rever suas percepções das pessoas / ferramentas envolvidas aqui, particularmente com a maneira como você vê as coisas.

    
por 15.04.2011 / 15:07
fonte
8

Convincente sobre o preço que o cliente tem que pagar para você

É preciso pagar o preço de mais esforço / custo: seu cliente ou você.

Você pode resolver este problema através do preço: A integração do serviço de sabão é mais cara para o cliente do que a integração do REST. Desta forma, o cliente tem a escolha.

    
por 15.04.2011 / 18:51
fonte
7

Você parece ter muitos preconceitos contra a Microsoft, que não gostava do SOAP. A história inicial do SOAP é de um projeto da Microsoft, é verdade. Mas você está ciente, espero, que tem sido uma recomendação do W3C há quase oito anos e que a especificação do SOAP é atualmente mantida pelo grupo de trabalho XML do W3C?

Na verdade, hoje em dia, com muito mais frequência, encontro serviços Web SOAP de desenvolvedores Java do que desenvolvedores .NET. Mas os desenvolvedores Java e .NET tendem a gostar, porque é suportado de forma limpa e fácil por praticamente todas as plataformas principais. Estou sinceramente surpreso por você ter tanta dificuldade em interagir com os serviços SOAP em PHP, não tenho experiência real em PHP, mas eu realmente teria pensado que ele suportaria um protocolo tão amplo e padronizado.

    
por 15.04.2011 / 14:33
fonte
2

Supondo que esses desenvolvedores estejam usando material .NET mais recente, eles devem estar usando o WCF. Então fazer o serviço rodar sobre REST vs. SOAP dificilmente é um desafio - apenas mude as ligações e elas estão prontas. A mesma base de código pode atender facilmente todos os lados.

Do lado do PHP, você pode não estar acostumado com o SOAP, mas trabalhei com sucesso com o SOAP no passado usando o nuSOAP. AFAIK, PHP 5+ tem uma pilha de SOAP preparada por isso não deve ser muito difícil trabalhar com as coisas.

    
por 15.04.2011 / 17:33
fonte
1

você está errado, Mike. O cliente tem um serviço SOAP no lugar, é melhor você deixar de lado seu ódio ao SOAP e trabalhar com ele. Se você quer o trabalho que é, você sempre pode devolver a tarefa e qualquer dinheiro já pago a você (mais possíveis taxas de rescisão e penalidades se estipulado no contrato) se você é muito preguiçoso, incompetente ou amarrado para usar qualquer coisa você não é fã de.

Em vez de fazer o seu trabalho, você está dizendo ao cliente que ele precisa fazer isso por você.

    
por 18.04.2011 / 10:19
fonte
0

Embora eu de todo coração concorde com as outras respostas dizendo que você tem um sério problema de perspectiva, eu tenho uma solução prática para abordar os dois pontos:

1) Why go to all the effort of creating a RESTful web service when I've already created a SOAP web service for you to use? You are just creating more work for me and I have other things to do.

Assumindo que os serviços SOAP são construídos usando o WCF, não é realmente nenhum esforço em todos os . Tudo que você precisa fazer é colocar um webHttpBinding e alguns atributos, e pronto, pronto, é REST. Ou pelo menos uma aproximação aproximada de REST para esse propósito.

2) There is no benefit to RESTful web services; SOAP is actually much better because I can create an object and then I can program it just like an object. Plus SOAP is used by enterprise developers and we are an enterprise development shop; REST is just not for serious use.

Pode não haver nenhum benefício de alterar sua arquitetura do SOAP para o restante, mas como o WCF permite configurar várias ligações no mesmo serviço, elas podem simplesmente executar o REST ( webHttpBinding ) e serviços SOAP lado a lado. Isso tem um benefício imediato e muito óbvio: é mais barato para você implementar porque você já suporta [JSON / POX / whatever]. Se 20 minutos de trabalho ao seu lado irão economizar $ 1000 em seu contrato, então tenho certeza que eles verão a vantagem.

    
por 15.04.2011 / 18:20
fonte
0

Diferentes linguagens de programação tendem a funcionar melhor com um estilo de interface de serviço da web. Por exemplo, eu sei que o Java é mais feliz com o SOAP na prática (há muito bom ferramental para isso nos dias de hoje) e um colega meu relata que Ruby está mais feliz com o REST. Além disso, algumas funcionalidades são strongmente restritas a SOAP ou REST; O SOAP não está vinculado ao HTTP e tem muito mais suporte para modelos de segurança sofisticados, enquanto o REST é definitivamente melhor para transferências de arquivos grandes. (Isso tudo é uma conseqüência do SOAP ser orientado a mensagens, enquanto o REST é mais orientado a conexões).

Dado que na verdade não existe um vencedor claro entre o SOAP e o REST em todas as situações, por que você está tentando forçar aqueles que pagariam para fazer mudanças apenas para acomodar seus preconceitos? Você não conhece todas as restrições em que está operando. Você não conhece todos os softwares clientes com os quais eles estão trabalhando. Em vez disso, você deve investigar como tornar seu software mais robusto em relação aos problemas de configuração identificados (por exemplo, por meio de embalagens alteradas ou dependências reduzidas). Pode até ser o suficiente para você melhorar a documentação sobre como instalar e usar seu código, ou até mesmo para você vender suporte de instalação.

    
por 18.04.2011 / 10:07
fonte