Un servizio Web Netflix o in stile Twitter dovrebbe utilizzare REST o SOAP? [chiuso]

Ho implementato due servizi REST: Twitter e Netflix. Entrambe le volte, ho faticato a trovare l'uso e la logica coinvolti nella decisione di esporre questi servizi come REST anziché SOAP. Spero che qualcuno possa indicarmi ciò che mi manca e spiegare perché REST è stato utilizzato come implementazione del servizio per servizi come questi.

1. L'implementazione di un servizio REST richiede infinitamente più tempo rispetto all'implementazione di un servizio SOAP. Esistono strumenti che tutti i linguaggi / framework / piattaforme moderni possono leggere in un WSDL e generare classi e client proxy. L'implementazione di un servizio REST è fatta a mano e - ottieni - leggendo la documentazione. Inoltre, durante l'implementazione di questi due servizi, è necessario fare delle "ipotesi" su cosa tornerà attraverso la pipe in quanto non esiste uno schema reale o un documento di riferimento.

2. Perché scrivere un servizio REST che restituisce comunque XML? L'unica differenza è che con REST non conosci i tipi che ogni elemento / attributo rappresenta - sei da solo per implementarlo e speri che un giorno non si verifichi una stringa in un campo che pensavi fosse sempre un int. SOAP definisce la struttura dei dati utilizzando WSDL, quindi questo è un gioco da ragazzi.

3. Ho sentito la lamentela che con SOAP hai il "sovraccarico" della busta SOAP. Al giorno d'oggi, dobbiamo davvero preoccuparci di una manciata di byte?

4. Ho sentito l'argomento che con REST puoi semplicemente inserire l'URL nel browser e vedere i dati. Certo, se il tuo servizio REST utilizza un'autenticazione semplice o nulla. Il servizio Netflix, ad esempio, utilizza OAuth che richiede di firmare e codificare le cose prima ancora di poter inviare la richiesta.

5. Perché abbiamo bisogno di un URL "leggibile" per ogni risorsa? Se stessimo utilizzando uno strumento per implementare il servizio, ci preoccupiamo davvero dell'URL effettivo?

Un canarino in una miniera di carbone.

Sto aspettando una domanda come questa da quasi un anno. Era inevitabile che questo giorno arrivasse e sono sicuro che vedremo molte altre domande come questa nei prossimi mesi.

I segnali di avvertimento

Hai assolutamente ragione, ci vuole più tempo per costruire client RESTful che client SOAP. I toolkit SOAP portano via un sacco di codice boilerplate e rendono gli oggetti proxy client disponibili quasi senza sforzo. Con uno strumento come Visual Studio e un URL del server posso accedere a oggetti remoti di complessità arbitraria, localmente in meno di cinque minuti.

I servizi che restituiscono application / xml e application / json sono così fastidiosi per gli sviluppatori client. Che cosa dovremmo fare con quel blocco di dati?

Fortunatamente, molti siti che forniscono servizi REST forniscono anche un gruppo di librerie client in modo da poterle utilizzare per ottenere l'accesso a un gruppo di oggetti fortemente tipizzati. Sembra un po 'stupido però. Se avessero usato SOAP avremmo potuto codificare noi stessi quelle classi proxy.

SOAP in testa, ah. È la latenza che uccide. Se le persone sono davvero preoccupate per il numero di byte in eccesso che attraversano il cavo, forse HTTP non è la scelta giusta. Hai visto quanti byte sono usati dall'intestazione user-agent?

Sì, hai mai provato a utilizzare un browser Web come strumento di debug per qualsiasi cosa diversa da HTML e JavaScript. Fidati di me fa schifo. Puoi usare solo due dei verbi, la memorizzazione nella cache si mette costantemente di mezzo, l'errore nella gestione ingoia così tante informazioni, è costantemente alla ricerca di un dannato favicon.ico. Mi spari e basta.

URL leggibile. Solo sostantivi, nessun verbo. Sì, è facile finché eseguiamo solo operazioni CRUD e dobbiamo solo accedere a una gerarchia di oggetti in un modo. Sfortunatamente la maggior parte delle applicazioni necessita di un po 'più di funzionalità.

Il disastro imminente

Esiste un carico metrico di sviluppatori che attualmente sviluppano applicazioni che si integrano con i servizi REST che stanno arrivando alla stessa serie di conclusioni che hai. Furono promessi semplicità, flessibilità, scalabilità, evolvibilità e il santo graal del riuso fortuito. Le caratteristiche del web stesso, come possono andare le cose male.

Tuttavia, stanno scoprendo che il controllo delle versioni è altrettanto un problema, ma il compilatore non aiuta a rilevare i problemi. Il codice client scritto a mano è un problema da mantenere con l'evoluzione delle strutture di dati e il refactoring degli URL. Progettare API attorno a soli nomi e quattro verbi può essere davvero difficile, specialmente con i fanatici di RESTful Url che ti dicono quando puoi e non puoi usare le stringhe di query.

Gli sviluppatori inizieranno a chiedersi perché stiamo sprecando i nostri sforzi nel supportare sia i formati Json che i formati Xml, perché non concentrare i nostri sforzi su uno solo e farlo bene?

Come sono andate le cose così male?

Ti dirò cosa è andato storto. Come sviluppatori lasciamo che i dipartimenti di marketing traggano vantaggio dalla nostra principale debolezza. La nostra eterna ricerca del proiettile d'argento ci ha accecato alla realtà di ciò che REST è veramente. In apparenza REST sembra così facile e semplice. Assegna un nome alle tue risorse con gli URL e usa GET, PUT, POST e DELETE. Diavolo, noi sviluppatori già sappiamo come farlo, ci occupiamo da anni di database con tabelle e colonne e istruzioni SQL con SELECT, INSERT, UPDATE e DELETE. Avrebbe dovuto essere un gioco da ragazzi.

Ci sono altre parti di REST che alcune persone discutono, come l'auto-descrittività e il vincolo ipermediale, ma questi vincoli non sono così semplici come l'identificazione delle risorse e l'interfaccia uniforme. Sembra aggiungere complessità in cui l'obiettivo desiderato è la semplicità.

Questa versione annacquata di REST è stata convalidata nella cultura degli sviluppatori in molti modi. Sono stati creati framework di server che hanno incoraggiato l'identificazione delle risorse e l'interfaccia uniforme, ma non hanno fatto nulla per supportare gli altri vincoli. I termini hanno iniziato a oscillare differenziando gli approcci, (HI-REST vs LO-REST, Corporate REST vs Academic REST, REST vs RESTful).

Alcune persone gridano che se non si applicano tutti i vincoli non è REST. Non otterrai i benefici. Non c'è mezzo RESTO. Ma quelle voci erano etichettate come fanatici religiosi che erano sconvolti dal fatto che il loro prezioso termine fosse stato rubato dall'oscurità e reso mainstream. Le persone gelose che cercano di far sembrare REST più difficile di quanto non sia.

REST, il termine, è diventato sicuramente mainstream. Quasi tutte le principali proprietà web che dispongono di un'API supportano "REST". Twitter e Netflix sono due di altissimo profilo. La cosa spaventosa è che posso solo pensare a un'API pubblica che è auto-descrittiva e ce ne sono alcune che implementano veramente il vincolo ipermediale. Sicuramente alcuni siti come StackOverflow e Gowalla supportano i collegamenti nelle loro risposte, ma ci sono enormi buchi nei loro collegamenti. L'API StackOverflow non ha una pagina principale. Immagina quanto sarebbe successo il sito Web se non ci fosse una home page per il sito!

Sei stato ingannato, temo

Se sei arrivato così lontano, la risposta breve alla tua domanda è che le API (Netflix e Twitter) non sono conformi a tutti i vincoli e quindi non otterrai i vantaggi che le API REST dovrebbero portare.

I client REST impiegano più tempo a svilupparsi rispetto ai client SOAP ma non sono legati a un servizio specifico, quindi dovresti essere in grado di riutilizzarli tra i servizi. Prendi il classico esempio di un browser web. A quanti servizi può accedere un browser Web? Che dire di un lettore di feed? Ora a quanti servizi diversi può accedere il client Twitter medio? Sì, solo uno.

I client REST non dovrebbero essere creati per interfacciarsi con un singolo servizio, dovrebbero essere creati per gestire tipi di media specifici che potrebbero essere serviti da qualsiasi servizio. La domanda ovvia è: come si può creare un client REST per un servizio che fornisce application / json o application / xml. Beh non puoi. Questo perché quei formati sono completamente inutili per un client REST. L'hai detto tu stesso,

devi fare "ipotesi" su cosa tornerà attraverso la pipe in quanto non esiste uno schema reale o un documento di riferimento

Hai assolutamente ragione per servizi come Twitter. Tuttavia, il vincolo auto-descrittivo in REST afferma che l'intestazione del tipo di contenuto HTTP dovrebbe descrivere esattamente il contenuto che viene trasmesso attraverso il filo. Fornire application / json e application / xml non dice nulla sul contenuto.

Quando si tratta di considerare le prestazioni dei sistemi basati su REST, è necessario guardare al quadro generale. Parlare di byte di inviluppo è come parlare di svolgimento di loop quando si confronta un ordinamento rapido con un ordinamento di shell. Ci sono scenari in cui SOAP può funzionare meglio e ci sono scenari in cui REST può funzionare meglio. Il contesto è tutto.

REST ottiene gran parte del suo vantaggio in termini di prestazioni essendo molto flessibile su quali tipi di supporti supporta e avendo un supporto sofisticato per la memorizzazione nella cache. Affinché la memorizzazione nella cache funzioni correttamente, è necessario rispettare quasi tutti i vincoli.

Il tuo ultimo punto sugli URL leggibili è di gran lunga il più ironico. Se ti impegni davvero con il vincolo ipermediale, ogni URL potrebbe essere un GUID e lo sviluppatore del client non perderebbe nulla in leggibilità.

Il fatto che gli URI debbano essere opachi per il client è una delle cose più importanti nello sviluppo di sistemi REST. Gli URL leggibili sono utili per lo sviluppatore del server e gli URL ben strutturati semplificano l'invio delle richieste da parte del framework del server, ma si tratta di dettagli di implementazione che non dovrebbero avere alcun impatto sugli sviluppatori che utilizzano l'API.

L'API di Twitter non è nemmeno vicina a essere RESTful ed è per questo che non sei in grado di vedere alcun vantaggio nell'usarlo su SOAP. L'API di Netflix è molto più vicina, ma l'uso di tipi di media generici dimostra che il mancato rispetto di un singolo vincolo può avere un impatto profondo sui vantaggi derivati ​​dal servizio.

Potrebbe non essere tutta colpa loro

Ho scaricato molto sui fornitori di servizi, ma ne bastano due per ballare RESTfully. Un servizio può seguire religiosamente tutti i vincoli e un cliente può comunque annullare facilmente tutti i vantaggi.

Se un codice hard client url per accedere a determinati tipi di risorse, impedisce al server di modificare tali URL. Qualsiasi tipo di costruzione di URL basata sulla conoscenza implicita di come il servizio struttura i suoi URL è una violazione.

Fare ipotesi sul tipo di rappresentazione che verrà restituito da un collegamento può portare a problemi. Fare ipotesi sul contenuto della rappresentazione in base a conoscenze che non sono esplicitamente dichiarate nelle intestazioni HTTP creerà sicuramente un accoppiamento che causerà dolore in futuro.

Avrebbero dovuto usare SOAP?

Personalmente, non la penso così. Il REST fatto correttamente consente a un sistema distribuito di evolversi a lungo termine. Se stai costruendo sistemi distribuiti con componenti sviluppati da persone diverse e devono durare per molti anni, REST è un'opzione piuttosto buona.

SOAP è un orientato agli oggetti , chiamata di procedura remota stack tecnologico. Funziona costruendo una nuova astrazione su un protocollo esistente (HTTP).

REST è un approccio orientato ai documenti , che utilizza semplicemente le funzionalità di un protocollo esistente (HTTP). "REST" è solo una parola d'ordine - il concetto è questo: basta usare il web nel modo in cui è stato progettato per funzionare!

In risposta alle modifiche alla domanda:

1. "L'implementazione di un servizio REST richiede infinitamente più tempo rispetto all'implementazione di un servizio SOAP."

   Ehm, no, non può essere infinitamente più lungo. E nei casi in cui ciò che stai cercando di recuperare è già un documento o un file , in realtà è molto più veloce . Ad esempio, le specifiche OGC per WMS (Web Mapping Service) definiscono sia una versione SOAP che REST del protocollo, e c'è un motivo per cui quasi nessuno implementa la versione SOAP - è perché se stai cercando di ottenere una mappa, è è molto più semplice creare un URL e recuperare i byte di immagine da quell'URL piuttosto che preoccuparsi di incapsularlo in un messaggio SOAP. Sì, concordo sul fatto che se il punto del servizio Web è trasferire un oggetto fortemente tipizzato in un modello a oggetti di dominio, SOAP è più adatto a tale uso.

2. "Perché scrivere un servizio REST che restituisce comunque XML?"

   Bene, sì, può essere sciocco. Ma dipende da cosa sia l'XML. Se esiste uno schema chiaramente definito per questo da qualche parte, allora non c'è ambiguità. Ad esempio, puoi pensare agli URL WSDL come a una sorta di servizio web RESTful per il recupero di informazioni su un servizio web. In questo caso, aggiungere l'overhead di un'altra richiesta SOAP sarebbe inutile.

   In generale, REST vince quando il contenuto che viene trasferito può essere pensato come un file, come una singola unità . SOAP vince quando il contenuto deve essere trattato come un oggetto con i membri .

3. "Ho sentito la lamentela che con SOAP hai il" sovraccarico "della busta SOAP. In questi tempi, dobbiamo davvero preoccuparci di una manciata di byte?"

   Sì. Non in ogni circostanza, ma ci sono siti con molto traffico dove fa la differenza. È sufficiente una differenza per superare le differenze semantiche dell'uso di SOAP invece di REST? Ne dubito. Se stai eseguendo un protocollo di remoting di oggetti e il numero di byte fa la differenza, SOAP probabilmente non è lo strumento adatto a te, forse dovresti invece utilizzare CORBA o DCOM.

4. "Ho sentito l'argomento che con REST puoi semplicemente inserire l'URL nel browser e vedere i dati."

   Sì, e questo è un grande argomento a favore di REST se ha senso visualizzare i dati in un browser . Ad esempio, con i dati delle immagini, è un modo semplice per eseguire il debug del servizio: basta incollare l'URL nella barra degli indirizzi del browser e vedere come appare l'immagine. Oppure, se i dati restituiti sono in XML e hai un foglio di stile XML di riferimento che viene convertito in HTML leggibile nel browser, otterrai il vantaggio del markup semantico e della visualizzazione semplice in un unico pacchetto. Ma hai ragione, questo vantaggio evapora soprattutto quando si lavora con schemi di autenticazione più complessi. Se non riesci a codificare tutte le informazioni di autenticazione in ciascuna richiesta HTTP , direi che non conta affatto come REST.

5. "Perché abbiamo bisogno di un URL" leggibile "per ogni risorsa? Se stessimo utilizzando uno strumento per implementare il servizio, ci preoccupiamo davvero dell'URL effettivo?"

   Beh, dipende. Perché abbiamo bisogno di URL leggibili per qualsiasi risorsa sul web? Puoi leggere il saggio di Tim Berners-Lee Gli URI fantastici non cambiano per la logica, ma fondamentalmente, fintanto che la risorsa potrebbe essere ancora utile in futuro, l'URI per quella risorsa dovrebbe rimanere lo stesso.

   Ovviamente, per le risorse transitorie (come il link "Denaro di oggi" nel saggio) non ce n'è bisogno, poiché la necessità di fare riferimento alla risorsa scompare se la risorsa corrispondente scompare. Ma per risorse più permanenti (come domande StackOverflow, ad esempio, o film su IMDB), vuoi avere un URL che funzioni per sempre. Quando si progetta un servizio Web, è necessario decidere se le risorse stesse potrebbero sopravvivere al proprio servizio e, in tal caso, REST è probabilmente la strada giusta da percorrere.

Per la cronaca, sì, ho sviluppato pagine Web da molto prima che esistessero NetFlix o Twitter. E no, non ho ancora avuto alcuna necessità o opportunità di implementare un client su NetFlix o sui servizi di Twitter. Ma anche se i loro servizi sono atrocemente difficili da lavorare, ciò non significa che la tecnologia su cui hanno implementato i loro servizi sia negativa - solo che quelle due implementazioni sono cattive.

Per farla breve: REST e SOAP sono solo strumenti . Ognuno di essi ha punti di forza e di debolezza. Se l'unico strumento che hai è un martello, ogni problema sembra un chiodo. Quindi conosci entrambi gli strumenti e impara come usarli correttamente, quindi scegli lo strumento giusto per ogni lavoro.

Una domanda onesta merita una risposta onesta. Ma prima, perché hai usato il testo di questa domanda come risposta a un'altra domanda se non pensavi fosse di natura retorica?

Comunque:

1. " Esistono strumenti che tutti i linguaggi / framework / piattaforme moderni possono leggere in un WSDL e generare classi e client proxy. L'implementazione di un servizio REST viene eseguita manualmente leggendo la documentazione. "

   Proprio come i fornitori di browser hanno letto e riletto la specifica HTML 4.01 su e giù per provare a implementare un'esperienza di navigazione coerente. Hai riflettuto sul fatto che i browser sono stati inventati molto prima dell'internet banking e dello stackoverflow, eppure puoi usare un browser per fare proprio queste cose. Ciò è reso possibile dal solo motivo per cui tutti accettano di utilizzare HTML (e formati correlati come CSS, JS, JPEG ecc.).

   Il blog in realtà non è così nuovo e qualcuno ha ideato AtomPub, che consente a qualsiasi software di blog di accedere e aggiornare i post in un blog, proprio come qualsiasi browser Web può accedere a qualsiasi pagina web. È abbastanza pulito e funziona a causa dei vincoli RESTful imposti dal protocollo.

   Ma per Twitter e Netflix non esiste un accordo universale sul fatto che "tutti i microblog esistenti utilizzeranno l'applicazione / tweet di tipo multimediale", principalmente perché il microblogging è così nuovo. Forse tra qualche anno alcuni servizi di microblogging si sistemeranno sulla stessa API in modo che Twitter, Facebook, Identica e possano interagire. Nessuna delle loro API esistenti è vicino a RESTful, per quanto sostengano, quindi non mi aspetto che accada presto.

   " Inoltre, durante l'implementazione di questi due servizi, devi fare" ipotesi "su ciò che tornerà attraverso la pipe in quanto non esiste uno schema reale o un documento di riferimento. "

   Hai colpito l'unghia sulla testa. REST è tutto distribuito e ipermediale, e questo lo riassume praticamente. Un browser osserva ciò che ottiene da una richiesta e lo mostra all'utente. Una pagina HTML di solito genera molte più richieste GET, ad esempio CSS, script e immagini. Un'immagine viene in genere visualizzata solo sullo schermo, viene eseguito JavaScript e così via. Ogni volta, il browser fa quello che fa perché ha trovato il collegamento in un tag <img>o <style>e il tipo di supporto di risposta era image/jpego text/css.

   Se Twitter crea un'API basata su hypermedia, probabilmente tornerà sempre application/tweetogni volta che segui un link a un tweet, ma il client non dovrebbe mai assumerlo e controlla sempre cosa ottiene prima di agire su di esso.

2. " Perché scrivere un servizio REST che restituisce comunque XML? "

   Tutto ciò si riduce ai tipi di media. Come HTML, se vedi un elemento che non hai idea di cosa significhi effettivamente, le specifiche HTML ti dicono di ignorarli e di elaborare il "corpo" del tag se ne ha uno. Allo stesso modo, la specifica dell'atomo ti dice di ignorare elementi sconosciuti e markup estranei (da diversi spazi dei nomi) e non elaborare il corpo (IIRC).

   Progettare tipi di media per domini problematici generici (come nel tipo di media HTML per il dominio problematico rich text ) è molto difficile. Creare tipi di media per domini problematici molto stretti è probabilmente molto più semplice (come un tweet). Ma è sempre una buona idea progettare per l'estensibilità e specificare come i client (e i server) dovrebbero reagire quando vedono elementi o elementi di dati che non corrispondono alle specifiche. JPEG, ad esempio, ha un tipo di record specifico dell'applicazione (ad esempio APP1) che viene utilizzato per contenere tutti i tipi di metadati.

3. " Ho sentito la lamentela che con SOAP hai il" sovraccarico "della busta SOAP. In questi tempi, dobbiamo davvero preoccuparci di una manciata di byte? "

   No, non lo facciamo. REST non è assolutamente un modo per essere efficiente attraverso il filo, ma in realtà scambia l'efficienza del filo. L'efficienza del REST deriva dalle possibilità di memorizzazione nella cache abilitate da tutti gli altri vincoli: Note di tesi di Fielding : Il compromesso, tuttavia, è che un'interfaccia uniforme si degrada efficienza, poiché le informazioni vengono trasferite in una forma standardizzata anziché in una specifica per le esigenze di un'applicazione. L'interfaccia REST è progettata per essere efficiente per il trasferimento di dati ipermediali di grandi dimensioni, ottimizzando per il caso comune del Web, ma dando come risultato un'interfaccia non ottimale per altre forme di interazione architettonica. Non penso che il sovraccarico del conteggio dei byte della busta SOAP sia una preoccupazione valida.

4. " Ho sentito l'argomento che con REST puoi semplicemente inserire l'URL nel browser e vedere i dati. "

   Sì, anche questo è un argomento non valido. Non funziona così. Anche se ha funzionato, le API REST più strette là fuori usano tipi di media di cui i browser non hanno idea e ancora non funzioneranno.

   Ma ci sono molte più possibilità rispetto a un browser per testare un'API basata su HTTP, come utilità da riga di comando o estensioni del browser che ti consentono di controllare quasi tutti gli aspetti di una richiesta HTTP, ispezionare le intestazioni di risposta e scoprire i collegamenti che devi seguire. Ma anche così, questo non è affatto facile come generare stub WSDL e creare un programma a tre linee per chiamare comunque la funzione.

5. " Perché abbiamo bisogno di un URL" leggibile "per ogni risorsa? Se stessimo utilizzando uno strumento per implementare il servizio, ci preoccupiamo davvero dell'URL effettivo? "

   Se guardi come funziona il web, sono abbastanza sicuro che gli umani siano molto contenti che l'URI per una pagina di Wikipedia sia simile a questo, http://en.wikipedia.org/wiki/Stack_overflowinvece di http://en.wikipedia.org/wiki/?oldid=376349090. Ma in realtà non è importante riposare. La cosa importante da provare per ottenere il giusto è scegliere di inserire nell'URI i dati rilevanti che non è probabile che cambino. Potresti pensare che l'ID del database non cambierà mai, ma cosa succede quando due set di dati devono essere uniti? Tutte le tue chiavi primarie cambiano. Il titolo della pagina (Stack_overflow) non cambierà.

Ci scusiamo per la lunga risposta, ma credo che questa domanda sia valida e non sia stata affrontata prima qui su SO. Sono sicuro che anche Darrel Miller aggiungerà la sua risposta una volta tornato.

Modifica: formattazione

Martin Fowler ha pubblicato un post sul modello di maturità Richardson che fa un ottimo lavoro spiegando la differenza tra SOAP e REST.

WSDL e altri protocolli a livello di documento sono ridondanti. Il protocollo HTTP supporta una serie molto più ricca di operazioni oltre a servire documenti e inviare moduli.

I sostenitori di REST sono a disagio con quella ridondanza.