Soap vs. rest: un approccio ibrido? [chiuso]

1

Possiedo un'architettura SOA corretta, con servizi Web definiti con WSDL e risposta alle richieste SOAP.
Ma questa applicazione ha anche un endpoint che risponde alla richiesta di json e alle risposte in formato json, quindi un po 'più come REST.

Il mio obiettivo è trasformare questa applicazione in una sorta di piattaforma, esponendo un'API, e devo capire tutte le migliori pratiche per creare questa API. La mia domanda riguarda il primissimo passaggio: come posso definire un'API da tale architettura ibrida?

Non è REST, ma è escluso usando SOAP per le richieste.
È ancora una web API? Esiste una "classificazione" accanto all'API REST? Sono un po 'confuso, leggo ovunque ma ancora non ne traggo il punto principale.

Già letto qui: Differenza tra API Web e servizio Web?

    
posta sissy 18.11.2015 - 17:16
fonte

3 risposte

2

Hai un'API che usa HTTP, nel mio libro che lo rende una "web API". Questo è un termine completamente generico che non implica nient'altro.

REST e Web Service sono due esempi di API Web. Il tuo non è REST e solo una parte di esso è un servizio Web SOAP.

Lo descriverei come "Un'API web che utilizza principalmente SOAP ma ha anche un endpoint più libero che utilizza richieste e risposte JSON".

Non c'è bisogno di pensare troppo a questa roba.

    
risposta data 19.11.2015 - 12:13
fonte
1

L'architettura REST riconosce che su base campo per campo, in definitiva, solo il C.R.U.D. operazioni che incapsulano TUTTE le definizioni di stato. Questo fa "rompere" le nostre cosiddette idee oldSchool sui confini delle transazioni e tutte quelle cose, ma solo perché qualcuno si è alzato e ha urlato l'acronimo "REST !!!!", non dobbiamo farlo solo.

Proprio perché è teoricamente possibile scomporre ogni trasferimento di oggetti tra sistemi / componenti in un'operazione CRUD basata su campo in stile REST, non significa che dobbiamo.

    
risposta data 19.11.2015 - 02:05
fonte
1

Questo è per il mondo accademico o per il mondo del lavoro?

Nel mondo del lavoro, JSON è molto più facile da analizzare di XML. Ad esempio, nel linguaggio PHP, i dati JSON vengono importati senza problemi in un array associativo (che è una struttura dati nativa di PHP e gestita da dozzine di funzioni PHP integrate). XML, tuttavia, di solito deve essere analizzato con funzioni di libreria speciali che sono più limitate. E anche allora, iterare i nodi di un documento XML è meno intuitivo.

SOAP ha anche dimostrato di essere un protocollo molto schizzinoso. Ho visto più occasioni del mondo reale in cui diversi adattatori SOAP non si sono parlati l'un l'altro con successo. Ci sono stati un sacco di errori di errore SOAP criptici lanciati. E l'ispezione approfondita e il perfezionamento dei messaggi SOAP hanno portato a vicoli ciechi inspiegabili.

Sono convinto che siano ragioni come queste che REST / JSON sembra sostituire lentamente SOAP / XML come formato e protocollo preferiti per lo scambio di dati nel settore.

Per quanto riguarda le specifiche teoriche REST o SOAP esatte e in che modo ciascuna API o fornitore le adotta in pratica ... non chiedere. Le specifiche teoriche sono per gli autori di documenti informatici. I risultati sono per le persone che cercano di affrontare le sfide aziendali e mettono il cibo sul loro tavolo alla fine della giornata. Il web è sempre stato un intreccio di tecnologie scadenti e inadeguate.

Se riesci a trovare un modo per scambiare dati in modo semplice, facile, affidabile, sicuro e coerente ... allora vinci. Più semplice, meglio è.

    
risposta data 19.11.2015 - 04:26
fonte

Leggi altre domande sui tag