Come convinco il mio capo a usare REST su SOAP? [duplicare]

SOAP o REST? Altre risposte fanno un buon lavoro per aiutarti a discutere il punto da una prospettiva tecnica. Tuttavia, prevedo che un KO è improbabile semplicemente perché tecnicamente potresti fare la maggior parte delle cose con entrambi gli approcci. Ci sono alcune eccezioni che possono portare a un knockout tecnico per esempio:

• se le richieste API devono essere instradabili tramite il middleware di messaggistica esterno pur consentendo al destinatario di autenticare e verificare il mittente originale, SOAP vince
• se si desidera utilizzare l'autenticazione dell'applicazione e la logica di controllo dell'accesso, REST può essere virtualmente un NOP, mentre per SOAP può essere un mini-progetto a sé stante.

Se non hai uno di questi requisiti eccezionali da non perdere e visto che non sei il capo (!), penso che il meglio che puoi sperare sia un pareggio perché, sebbene la decisione appaia "tecnica" rimarrà soggettivo.

Ma .. se vuoi prendere la decisione migliore (e non solo vincere una discussione), forse puoi spingere a guardare questo, con il tuo capo, in un modo diverso:

Poiché "hai bisogno di creare un'API per il nostro sistema", suppongo che questo non sia solo un dettaglio tecnico interno del tuo sistema e "Gli argomenti tecnici sono per tecnici - cioè, persone che faranno il lavoro "non si applica. C'è un gruppo di persone là fuori da qualche parte che dovrà affrontare qualunque cosa tu trasporti, e penso che probabilmente ti piacerebbe che lo usassero e lo amassero? In tal caso:

Ciò di cui hanno bisogno per l'API probabilmente supera qualsiasi argomento tu o il tuo capo possano venire in mente (almeno questo è quello che penserebbero)

es. se vogliono integrarsi con la tua API tramite BizTalk o somesuch, allora forse SOAP lo è (documento letterale e tutto). Ma se sono programmatori che scriveranno alla tua API, SOAP potrebbe essere la campana a morto per l'adozione, mentre REST ti renderà eroi.

Se sai già chi sono queste persone, penso che dovresti chiedere loro di cosa hanno bisogno da un'API. Se si tratta di un "nuovo mercato", allora forse prova a intrecciare i migliori rappresentanti che puoi trovare, o almeno provare a descrivere e capire che cosa significherà "l'ambiente del cliente rappresentativo" per aiutare a informare la decisione.

In altre parole, ti consiglio di vedere se riesci a trovare la voce del cliente da veri clienti esterni o da altri dell'organizzazione o dai partner che possono eseguire un buon lavoro intermedio prima del lancio .

(allora quando ti dicono "REST! Non osare darci qualche mostruosità SOAP Rube Goldberg", puoi sorridere consapevolmente al tuo capo)

È un processo in due fasi:

1. Convinci il tuo capo che dovrebbe essere il team tecnico a scegliere la direzione tecnica, non la gestione.

2. Scegli REST. O SAPONE. O POX. O Qualunque.

Gli argomenti tecnici sono per persone tecniche, ovvero persone che faranno il lavoro. Una volta che il capo inizia a decidere la tecnologia, hai un problema sociale. Devi convincere il tuo capo a togliersi le mani dalla torta e lasciarti fare il tuo lavoro.

Proporrei un test: codice due soluzioni che fanno lo stesso servizio molto semplice. Usa SOAP e un'API REST-ful e confronta i risultati. Considerati gli strumenti oggi non ci dovrebbe essere molta differenza. Puoi alzare un servizio abbastanza facilmente.

Quindi modifica l'API. È mia esperienza che uno sviluppatore che modifica un'API REST può facilmente apportare le modifiche perché si sta occupando di un protocal concettuale che capiscono. È anche mia esperienza che l'API SOAP si baserà su strumenti per realizzare qualsiasi cosa. Puoi farlo a mano ma pochissime persone lo fanno (per ovvi motivi) una volta che vedi codice / markup generato.

Ancora meglio ... chiedi al tuo capo di implementare SOAP.

Dovresti esaminare i diversi ambienti, dove viene utilizzato il tuo sistema e se questi ambienti fanno comunicazione inter-sistema principalmente in modo riposante, che il tuo sistema dovrebbe offrire anche tale interfaccia. (Significa che, se i tuoi clienti lo usano, anche il tuo sistema dovrebbe farlo.)

Invece di entrare nel perpetuo boss contro gli argomenti del coder prendiamo alcuni casi specifici e valutiamo l'idoneità del modello. Gli amanti del REST sono i benvenuti a confutare con argomenti logici e basati sui fatti -

Scopo: Remoting dei servizi / superamento delle restrizioni / binding del firewall con protocolli come HTTP

Opzioni: SOAP / REST (scartando i protocolli come RMI ecc. perché è fuori dal contesto)

use case 1: ho bisogno di binding ottimizzato (JMS / RMI) per diversi motivi come   a) Propagazione del contesto delle transazioni   b) grande scambio di carico utile   c) QoS rigoroso Qui, la mia scelta sarà SAPONE. Ho visto qualcuno menzionato sui problemi di interoperabilità con tipi complessi - spiega perché pensi che la conformità al profilo di base di WS-I non possa risolvere il tuo problema (ad esempio preferibilmente).

use case 2: Ho bisogno di propagazione dell'identità (asserzione) in un ambiente federato di intermediari fidati (attivi o passivi). Questo è un caso d'uso B2B. Non credo di avere un modo definito di allegare criteri con un endpoint REST. Quindi il servizio basato su SOAP diventa la scelta più ovvia

use case 3: ho bisogno di un'API di gestione per il mio PaaS. JMX mbeans devono essere esposti come servizi. Questo è un po 'punto per punto in natura. La larghezza di banda è un vincolo. La governance non è una preoccupazione. Il client basato sul browser lo rende più utilizzabile. HTTPS è abbastanza buono in questo caso, non ho intenzione di preoccuparmi della sicurezza a livello di messaggio. Avrò una scelta su REST perché non ho bisogno delle sottigliezze e complessità di SOAP in questo caso particolare.

use-case 4: Ho bisogno di un supporto affidabile dei messaggi. WS-RM può risolvere per questo. SOAP è il modello ovvio qui perché il motore SOAP / app server ha il supporto OOTB per la configurazione WS-RM.

use case 5: Devo invocare più endpoint in un contesto TX e HTTP è l'unica opzione disponibile per il protocollo di trasporto. Non penso che REST supporti WS-AT, quindi vado con SOAP

use case 6: ho bisogno di un endpoint asincrono. Non voglio ritardare inutilmente il thread di richiesta. SOAP sarà la scelta.

use case 7: Voglio eliminare il sovraccarico non necessario dell'XML per convertire i tipi di dati, in quanto i dati verranno comunque visualizzati su un'interfaccia utente con una trasformazione minima o nulla. REST con JSON sarebbe la mia scelta.

In generale, se penso a DATA / RESOURCE preferirei REST Se penso a operazioni / metodi (sincronizzazione / asincronia .. stato..messaggio livello di sicurezza..scalabilità) sono propenso a usare SOAP

Non permettermi di introdurre la governance e l'angolo SOA qui. Io non voglio sembrare "one-of-those" in un forum dedicato agli sviluppatori.

Sentitevi liberi di correggermi in precedenza ..

Uno degli importanti vantaggi di REST che non è stato sollevato è che è intercambiabile e facilmente scalabile. SOAP non è collegabile, poiché è una richiesta POST .