Convincere un cliente a offrire un servizio Web RESTful invece di un servizio SOAP? [chiuso]

Quindi, mentre tendo ad essere d'accordo con la tua posizione, ho ancora intenzione di lanciare alcune idee per l'equilibrio. Innanzitutto il 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."

Il problema è che hanno già lavorato. Più che probabile, in base alla descrizione, questi servizi Web sono servizi WCF. Microsoft si è davvero presa la briga di creare servizi Web basati su SOAP, quindi dal punto di vista dello sviluppo / manutenzione ha senso dal punto di vista del cliente solo per utilizzare lo stack WCF. Se avessero avuto il problema di lanciare lo stack SOAP da soli, non avresti una vendita così difficile.

Il problema, a mio avviso, è che Wordpress (una tecnologia PHP) non è in grado di gestire SOAP. SOAP è un adattamento "standard" non standard del protocollo HTTP. In breve, al posto della tipica richiesta e delle informazioni dell'intestazione HTTP come parte di un normale client, esiste anche un corpo XML. Questo XML è solitamente mappato agli oggetti e ha le proprie informazioni di intestazione. In breve, non è qualcosa che PHP è progettato per out of the box. Stai utilizzando PHP: SOAP ? Speriamo che semplifichi l'utilizzo di SOAP.

Tuttavia, più avanti sulla strategia pratica.

"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."

Questo è in realtà molto più facile da gestire. In breve, la maggior parte dei servizi Web che ho visto hanno modelli di richiesta molto semplici. Tutto ciò che devi passare è un ID e un token di autenticazione. Questo è il tipo insignificante di interazione su cui prosperano i servizi web RESTful. È possibile restituire facilmente una rappresentazione legata XML o JSON dell'oggetto. In effetti, lo stack MS ha la logica di binding per entrambi di quelli. Molto raramente un cliente ha bisogno di inviare dati gerarchici complessi al server.

modi pratici per rendere felici entrambi

So che può sembrare sciocco, ma hai considerato un wrapper del servizio web? Qualcosa che traduca le chiamate REST devi rendere felice Wordpress nelle chiamate basate su SOAP che rendono felici i servizi WCF del tuo cliente? Questo potrebbe essere il modo più pacifico di affrontarlo. Avendo fatto i servizi web RESTful usando ASP.NET MVC, sarebbe banale tenere le cose nello stack Microsoft dove ne avete bisogno ed eseguire la traduzione nello stack PHP in modo sano.

Ecco un pensiero per te: perché non dai al cliente ciò che chiedono? Sono, dopo tutto, il tuo cliente e il loro primo punto è estremamente valido. Perché dovrebbero svolgere un lavoro extra a causa dei tuoi scrupoli di seconda mano sui servizi SOAP?

Se ritieni sinceramente che ciò aumenterà il tuo carico di lavoro, assicurati che il tipo di servizio fornito sia scritto nel contratto e fai più offerte dove specificano il SOAP.

Se dovessi avere ragione, piuttosto che un troll di linguaggio con maniaco rispetto agli sviluppatori di Microsoft-stack, la prossima volta avrai un argomento migliore rispetto a chiamare i loro sviluppatori (che probabilmente si fidano molto di più di quanto credono tu) "grasso, muto e felice".

La mia risposta è che non puoi. Non conosco i tuoi clienti, ma dalla tua descrizione non suonano come se fossero ambivalenti nella loro determinazione. Ti hanno chiesto di fornire un servizio, quindi ti suggerisco di fornirlo o andare avanti.

In una nota supplementare, gran parte del corpo della domanda riguarda accuse nei confronti di Microsoft per la creazione di programmatori pigri. Questa è la tua accusa di Microsoft o è rilevante per i programmatori che hanno preso la decisione di usare SOAP? Li stai chiamando pigri o stai semplicemente facendo cazzate in una compagnia di software? Sospetto che ciò non tenga conto della politica di indurli a utilizzare una tecnologia "migliore" di quanto non lo sia per te che costringe la tua zona di comfort alla gola. Il mio suggerimento per uno sviluppatore freelance (che è quello che sto assumendo qui) è che è necessario imparare ad adattarsi alle esigenze del cliente. La raccomandazione di soluzioni alternative è appropriata solo se è possibile mostrare un'analisi costi / benefici tangibile o se il cliente non ha una reale conoscenza del processo in questione e sta prendendo decisioni non informate.

Oltre a ciò, aiuta a seguire l'assioma: il cliente non ha sempre ragione, ma il cliente è quello che paga le bollette.

Nota: non sto affatto dicendo che tu abbia ragione O torto. I miei commenti sono semplicemente intesi a indicare cosa può essere considerato confuso da parte vostra rispetto a come funziona la relazione cliente / fornitore. Sto anche tentando di farti rivedere le tue percezioni delle persone / strumenti coinvolti qui, in particolare con il modo in cui visualizzi le cose.

Convincere sul prezzo che il cliente deve pagare per te

Uno deve pagare il prezzo di più sforzo / costo: il tuo cliente o tu.

È possibile risolvere questo problema attraverso il prezzo: l'integrazione del servizio sapone è più costosa per il cliente rispetto all'integrazione di REST. In questo modo il cliente ha la scelta.

Sembra che tu abbia un sacco di pregiudizi contro Microsoft legato alla tua avversione per SOAP. La storia precedente di SOAP proviene da un progetto Microsoft, è vero. Ma sei consapevole, spero, che sia stata una raccomandazione del W3C per quasi otto anni e che la specifica SOAP sia attualmente gestita dal gruppo di lavoro XML del W3C?

In realtà, oggigiorno, incontro molto più spesso i servizi web SOAP dagli sviluppatori Java rispetto agli sviluppatori .NET. Ma gli sviluppatori Java e .NET tendono ad apprezzarlo perché è pulito e facilmente supportato da quasi tutte le principali piattaforme. Sono sinceramente sorpreso dal fatto che tu stia avendo difficoltà a interagire con i servizi SOAP in PHP, non ho una vera esperienza di PHP, ma avrei davvero pensato che avrebbe supportato un protocollo così diffuso e standardizzato a lungo.

Supponendo che questi sviluppatori stiano utilizzando le novità .NET, dovrebbero usare WCF. Quindi fare il servizio su REST vs. SOAP non è certo una sfida: basta cambiare i binding e sono fatti. La stessa base di codice può facilmente servire tutti i lati.

Dal lato PHP, potresti non essere abituato a SOAP ma ho già lavorato con successo con SOAP in passato usando nuSOAP. AFAIK, PHP 5+ hanno uno stack SOAP cotto in modo che non dovrebbe essere troppo difficile lavorare con il materiale.

ti sbagli, Mike. Il cliente ha un servizio SOAP in atto, è meglio mettere da parte il tuo odio per SOAP e lavorare con esso. Se vuoi il lavoro che è, puoi sempre restituire l'incarico e tutti i soldi già pagati a te (più eventuali indennità e penali se stipulato nel contratto) se sei troppo pigro, incompetente o teso a usare qualsiasi cosa non sei un fan di.

Invece di fare il tuo lavoro, stai dicendo al cliente che devono farlo per te.

Anche se sono pienamente d'accordo con le altre risposte che ti dicono che hai un serio problema di prospettiva, ho una soluzione pratica per affrontare entrambi i punti:

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.

Supponendo che i servizi SOAP siano costruiti usando WCF, in realtà non è affatto uno sforzo . Tutto quello che devi fare è schiaffeggiare su webHttpBinding e un paio di attributi, e boom, hai finito, è REST. O almeno un'approssimazione abbastanza vicina di REST per questo scopo.

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.

Potrebbe non esserci alcun vantaggio nel cambiare la loro architettura da SOAP a riposo, ma poiché WCF consente di impostare più binding sullo stesso servizio, è sufficiente eseguire il REST ( webHttpBinding ) e servizi SOAP fianco a fianco. Questo ha un vantaggio immediato e molto ovvio: è più economico implementare perché supporti già [JSON / POX / qualunque]. Se 20 minuti di lavoro da parte loro salveranno $ 1000 sul tuo contratto, sono sicuro che vedranno il vantaggio.

Diversi linguaggi di programmazione tendono a funzionare meglio con uno stile di interfaccia di servizio web. Ad esempio, so che Java è più felice con SOAP in pratica (ci sono un sacco di strumenti veramente validi per questo in questi giorni) e un mio collega riferisce che Ruby è più felice con REST. Inoltre, alcune funzionalità sono strongmente limitate a SOAP o REST; SOAP non è legato ad HTTP e ha molto più supporto per sofisticati modelli di sicurezza, mentre REST è decisamente migliore per il trasferimento di file di grandi dimensioni. (Ciò è dovuto al fatto che SOAP è orientato ai messaggi mentre REST è più orientato alla connessione.)

Dato che in ogni caso non esiste un chiaro vincitore tra SOAP e REST in tutte le situazioni, perché stai cercando di costringere coloro che ti pagherebbero per apportare modifiche solo per soddisfare i tuoi pregiudizi? Non si conoscono tutti i vincoli su cui stanno operando. Non si conosce tutto il software client con cui stanno facendo funzionare i propri servizi. Invece, dovresti investigare su come rendere il tuo software più robusto rispetto ai problemi di configurazione che hai identificato (ad es. Attraverso un packaging modificato o dipendenze ridotte). Potrebbe anche essere sufficiente per migliorare la documentazione su come installare e utilizzare il codice, o anche per vendere il supporto per l'installazione.