rest - protocollo - soap web service




Trasferimento dello stato di rappresentazione(REST) e Simple Object Access Protocol(SOAP) (10)

Semplice spiegazione su SOAP e REST

SOAP - "Simple Object Access Protocol"

SOAP è un metodo per trasferire messaggi o piccole quantità di informazioni su Internet. I messaggi SOAP sono formattati in XML e generalmente inviati tramite HTTP (protocollo di trasferimento ipertestuale).

Riposo: trasferimento dello stato di rappresentanza

Rest è un modo semplice di inviare e ricevere dati tra client e server e non ha molti standard definiti. È possibile inviare e ricevere dati come JSON, XML o anche testo semplice. È leggero rispetto a SOAP.

Qualcuno può spiegare cos'è REST e cos'è SOAP in inglese? E come funzionano i servizi Web?


Bene, inizierò con la seconda domanda: quali sono i servizi Web? , per ovvie ragioni.

I servizi Web sono essenzialmente parti di logica (a cui potresti vagamente fare riferimento come metodo) che espongono determinate funzionalità o dati. Il client che implementa (tecnicamente parlando, consumare è la parola) ha solo bisogno di sapere quali sono i parametri che il metodo accetterà e il tipo di dati che restituirà (se lo farà).

Il seguente link dice tutto su REST & SOAP in modo estremamente lucido.

REST vs SOAP

Se vuoi anche sapere quando scegliere cosa (REST o SOAP), motivo in più per attraversarlo!


Il problema con SOAP è che è in conflitto con gli ideali dietro lo stack HTTP. Qualsiasi middleware dovrebbe essere in grado di funzionare con le richieste HTTP senza comprendere il contenuto della richiesta o della risposta, ma per esempio un normale server di caching HTTP non funzionerà con le richieste SOAP senza sapere solo quali parti del contenuto SOAP sono importanti per la memorizzazione nella cache. SOAP usa semplicemente HTTP come wrapper per il proprio protocollo di comunicazione, come un proxy.


Mi piace la risposta di Brian R. Bondy. Volevo solo aggiungere che Wikipedia fornisce una chiara descrizione di REST . L'articolo lo distingue da SOAP.

REST è uno scambio di informazioni sullo stato, fatto nel modo più semplice possibile.

SOAP è un protocollo di messaggi che utilizza XML.

Uno dei motivi principali per cui molte persone sono passate da SOAP a REST è che gli standard WS- * (chiamati WS splat) associati ai servizi Web basati su SOAP sono ESTREMAMENTE complicati. Vedi wikipedia per un elenco delle specifiche. Ognuna di queste specifiche è molto complicata.

EDIT: per qualche motivo i collegamenti non vengono visualizzati correttamente. REST = REST

WS- * = http://en.wikipedia.org/wiki/WS- *



REST è uno stile di architettura per la progettazione di applicazioni in rete. L'idea è che, piuttosto che utilizzare meccanismi complessi come CORBA, RPC o SOAP per connettersi tra le macchine, il semplice HTTP viene utilizzato per effettuare chiamate tra le macchine.


Servizi Web basati su SOAP In breve, il modello SOAPbased Services vede il mondo come un ecosistema di coetanei che non possono controllarsi a vicenda, ma devono collaborare onorando i contratti pubblicati. È un modello valido del mondo reale disordinato e i contratti basati su metadati formano l'interfaccia di servizio SOAP.

possiamo ancora associare SOAP con Remote Procedure Calls basate su XML, ma la tecnologia dei servizi Web basata su SOAP è emersa in un modello di messaggistica flessibile e potente.

SOAP presuppone che tutti i sistemi siano indipendenti e che nessun sistema abbia alcuna conoscenza degli interni di un'altra funzionalità interna. La maggior parte di tali sistemi può fare è inviare messaggi l'un l'altro e sperare che vengano messi in atto. I sistemi pubblicano contratti che si impegnano a onorare e altri sistemi si affidano a questi contratti per scambiare messaggi con loro.

I contratti tra i sistemi vengono definiti collettivamente metadati e comprendono le descrizioni dei servizi, i modelli di scambio dei messaggi supportati e le politiche che disciplinano le qualità del servizio (un servizio potrebbe dover essere crittografato, consegnato in modo affidabile, ecc.) Una descrizione del servizio, a sua volta, è dettagliata specifica dei dati (documenti del messaggio) che verranno inviati e ricevuti dal sistema. I documenti sono descritti utilizzando un linguaggio di descrizione XML come XML Schema Definition. Finché tutti i sistemi onorano i loro contratti pubblicati, possono interagire e le modifiche ai componenti interni dei sistemi non influiscono su nessun altro. Ogni sistema è responsabile della traduzione delle proprie implementazioni interne da e verso i suoi contratti

REST - Trasferimento dello stato rappresentativo. Il protocollo fisico è HTTP. Fondamentalmente, REST è che tutte le risorse distinte sul web sono identificabili in modo univoco da un URL. Tutte le operazioni che possono essere eseguite su queste risorse possono essere descritte da un insieme limitato di verbi (i verbi "CRUD") che a loro volta si associano ai verbi HTTP.

Il REST è molto meno "pesante" di SOAP.

Funzionamento del servizio web


Sia i servizi Web SOAP che i servizi web REST possono utilizzare anche il protocollo HTTP e altri protocolli (solo per menzionare SOAP può essere il protocollo sottostante di REST). Parlerò solo del protocollo HTTP relativo SOAP e REST, perché questo è l'utilizzo più frequente di essi.

SAPONE

SOAP ("semplice" protocollo di accesso agli oggetti) è un protocollo (e uno standard W3C ). Definisce come creare, inviare ed elaborare i messaggi SOAP.

  • I messaggi SOAP sono documenti XML con una struttura specifica: contengono una busta che contiene l'intestazione e la sezione del corpo. Il corpo contiene i dati effettivi, che vogliamo inviare, in un formato XML. Esistono due stili di codifica , ma in genere vengono scelti letterali , il che significa che la nostra applicazione o il suo driver SOAP esegue la serializzazione XML e la serializzazione dei dati.

  • I messaggi SOAP viaggiano come messaggi HTTP con sottotipo SOAP + XML MIME. Questi messaggi HTTP possono essere multipart, quindi facoltativamente possiamo allegare file ai messaggi SOAP.

  • Ovviamente utilizziamo un'architettura client-server, quindi i client SOAP inviano richieste ai webser SOAP e i servizi inviano risposte ai client. La maggior parte dei servizi Web utilizza un file WSDL per descrivere il servizio. Il file WSDL contiene lo schema XML (XSD qui di seguito) dei dati che si desidera inviare e il binding WSDL che definisce il modo in cui il servizio Web è associato al protocollo HTTP. Esistono due stili di rilegatura : RPC e documento. Con lo stile RPC che associa il corpo SOAP contiene la rappresentazione di una chiamata di operazione con i parametri (richieste HTTP) oi valori di ritorno (risposta HTTP). I parametri e i valori di ritorno sono convalidati rispetto all'XSD. In base allo stile del documento che lega il corpo SOAP contiene un documento XML che viene convalidato rispetto all'XSD. Penso che lo stile di rilegatura del documento sia più adatto ai sistemi basati su eventi, ma non ho mai usato questo stile vincolante. Lo stile di binding RPC è più diffuso, quindi molte persone usano SOAP per scopi XML / RPC per applicazioni distribuite. I servizi web di solito si trovano reciprocamente chiedendo un server UDDI . I server UDDI sono registri che memorizzano la posizione dei servizi Web.

SOAP RPC

Quindi, a mio parere, il webservice SOAP più diffuso utilizza lo stile di binding RPC e lo stile di codifica letterale e ha le seguenti proprietà:

  • Mappa gli URL alle operazioni.
  • Invia messaggi con sottotipo SOAP + XML MIME.
  • Può avere un archivio di sessioni lato server, non ci sono vincoli a riguardo.
  • I driver del client SOAP utilizzano il file WSDL del servizio per convertire le operazioni RPC in metodi. L'applicazione lato client comunica con il servizio web SOAP chiamando questi metodi. Pertanto, la maggior parte dei client SOAP si interrompe in base alle modifiche dell'interfaccia (nomi dei metodi risultanti e / o modifiche dei parametri).
  • È possibile scrivere client SOAP che non interrompono le modifiche dell'interfaccia usando RDF e trovano operazioni per semantica, ma i servizi web semantici sono molto rari e non hanno necessariamente un client che non si rompe (credo).

RIPOSO

REST (trasferimento dello stato di rappresentazione) è uno stile di architettura descritto nella dissertation di Roy Fielding. Non riguarda i protocolli come fa SOAP. Inizia con uno stile di architettura null senza vincoli e definisce i vincoli dell'architettura REST uno per uno. Le persone usano il termine RESTful per i webservices che soddisfano tutti i vincoli REST, ma secondo Roy Fielding, non ci sono cose come i livelli REST . Quando un servizio web non soddisfa ogni singolo vincolo REST, non si tratta di un servizio web REST.

Vincoli REST

  • Architettura client - server - Penso che questa parte sia familiare a tutti. I client REST comunicano con i servizi web REST, i servizi Web mantengono i dati comuni - lo stato delle risorse in futuro - e lo servono ai client.
  • Stateless - La parte "trasferimento dello stato" dell'abbreviazione: REST. I client mantengono lo stato del client (stato sessione / applicazione), quindi i servizi non devono avere una memoria di sessione. I clienti trasferiscono la parte rilevante dello stato del cliente da ogni richiesta ai servizi che rispondono con la parte rilevante dello stato della risorsa (gestita da loro). Quindi le richieste non hanno contesto, contengono sempre le informazioni necessarie per elaborarle. Ad esempio tramite HTTP basic auth il nome utente e la password vengono memorizzati dal client e li invia ad ogni richiesta, quindi l'autenticazione avviene a ogni richiesta. Questo è molto diverso dalle normali webapplications in cui l'autenticazione avviene solo tramite login. Possiamo utilizzare qualsiasi meccanismo di archiviazione dati lato client come in-memory (javascript), cookie, localStorage e così via ... per mantenere alcune parti dello stato del client, se vogliamo. La ragione del vincolo di apolidia, ovvero che il server scala bene, anche con un carico molto elevato (milioni di utenti), quando non deve mantenere la sessione di ogni singolo client.
  • Cache: la risposta deve contenere informazioni su di essa possono essere memorizzate nella cache dal client o meno. Ciò migliora ulteriormente la scalabilità.
  • Interfaccia uniforme

    • Identificazione delle risorse - La risorsa REST è la stessa della risorsa RDF . Secondo Fielding, se puoi nominare qualcosa, allora può essere una risorsa, ad esempio: "il meteo locale corrente" può essere una risorsa, o "il tuo cellulare" può essere una risorsa, oppure "un documento web specifico" può essere una risorsa. Per identificare una risorsa è possibile utilizzare identificatori di risorse: URL e URN (ad esempio il numero ISBN di libri ). Un singolo identificatore deve appartenere solo a una risorsa specifica, ma una singola risorsa può avere molti identificatori, che spesso sfruttiamo per esempio dall'impaginazione con URL come https://example.com/api/v1/users?offset=50&count=25 . Gli URL hanno alcune specifications , ad esempio URL con gli stessi percorsi ma query diverse non sono identiche oppure la parte del percorso deve contenere i dati gerarchici dell'URL e la parte della query deve contenere i dati non gerarchici. Queste sono le basi su come creare URL per REST. Btw. la struttura dell'URL è importante solo per gli sviluppatori di servizi, un vero client REST non lo riguarda. Un'altra domanda frequente è il versioning delle API, che è facile, perché secondo Fielding l'unica cosa costante per risorsa è la semantica. Se la semantica cambia, puoi aggiungere un nuovo numero di versione. È possibile utilizzare il controllo delle versioni classico dei numeri 3 e aggiungere solo il numero principale agli URL ( https://example.com/api/v1/ ). Quindi con le modifiche retroattive non succede nulla, con modifiche non retrocompatibili si avrà una semantica compatibile non retrocompatibile con una nuova radice API https://example.com/api/v2/ . Quindi i vecchi client non si romperanno, perché possono usare https://example.com/api/v1/ con la vecchia semantica.
    • Manipolazione delle risorse tramite rappresentazioni: è possibile manipolare i dati relativi alle risorse (stato della risorsa) inviando la rappresentazione prevista delle risorse, insieme al metodo HTTP e all'identificativo della risorsa, al servizio REST. Ad esempio, se si desidera rinominare un utente dopo il matrimonio, è possibile inviare una PATCH https://example.com/api/v1/users/1 {name: "Mrs Smith"} richiesta dove il {name: "Mrs Smith"} è una rappresentazione JSON dello stato di risorsa previsto, in altre parole: il nuovo nome. Questo accade vica-versa, il servizio invia rappresentazioni di risorse ai clienti per cambiare i loro stati. Ad esempio, se vogliamo leggere il nuovo nome, possiamo inviare una richiesta di recupero GET https://example.com/api/v1/users/1?fields="name" , che restituisce un 200 ok, {name: "Mrs Smith"} risposta. Quindi possiamo usare questa rappresentazione per cambiare lo stato del cliente, ad esempio possiamo mostrare un "Benvenuto alla nostra pagina Mrs Smith!" Messaggio. Una risorsa può avere molte rappresentazioni a seconda dell'identificativo della risorsa (URL) o dell'intestazione di accept abbiamo inviato con la richiesta. Ad esempio possiamo inviare un'immagine di Mrs Smith (probabilmente non nuda) se è richiesta l' image/jpeg .
    • Messaggi auto-descrittivi: i messaggi devono contenere informazioni su come elaborarli. Ad esempio il metodo URI e HTTP, l'intestazione del tipo di contenuto, le intestazioni della cache, RDF che descrive il significato dei dati, ecc. È importante utilizzare metodi standard. È importante conoscere le specification dei metodi HTTP. Per esempio, GET significa recuperare informazioni identificate dall'URL della richiesta, DELETE significa chiedere al server di eliminare la risorsa identificata dall'URL specificato e così via ... I codici di stato HTTP hanno anche una specification , per esempio 200 significa successo, 201 significa è stata creata una nuova risorsa, 404 significa che la risorsa richiesta non è stata trovata sul server, ecc ... L'utilizzo degli standard esistenti è una parte importante di REST.
    • Hypermedia come motore di stato dell'applicazione (HATEOAS in futuro) - Hypermedia è un tipo di supporto che può contenere collegamenti ipertestuali. Dal Web seguiamo i collegamenti, descritti da un formato ipermediale (solitamente HTML), per raggiungere un obiettivo, invece di digitare gli URL nella barra degli indirizzi. REST segue lo stesso concetto, le rappresentazioni inviate dal servizio possono contenere collegamenti ipertestuali. Utilizziamo questi collegamenti ipertestuali per inviare richieste al servizio. Con la risposta otteniamo dati (e probabilmente più link) che possiamo usare per costruire il nuovo stato client, e così via ... Ecco perché hypermedia è il motore dello stato dell'applicazione (stato client). Probabilmente ti chiedi come fanno i clienti a riconoscere e seguire i collegamenti ipertestuali? Per gli umani è piuttosto semplice, leggiamo il titolo del link, magari riempiamo i campi di input, e dopo di ciò basta un solo clic. Dalle macchine dobbiamo aggiungere semantica ai collegamenti con RDF (di JSON-LD con Hydra ) o con soluzioni specifiche per l'ipermedia (ad esempio le relazioni di link IANA e i tipi MIME specifici del fornitore di HAL+JSON ). Esistono molti formati ipermediali XML e JSON leggibili meccanicamente, solo una breve lista di essi:

      A volte è difficile scegliere ...

  • Sistema a strati: possiamo utilizzare più livelli tra i client e i servizi. Nessuno di loro dovrebbe sapere su tutti questi livelli addizionali, solo di livello proprio accanto ad esso. Questi livelli possono migliorare la scalabilità applicando cache e bilanciamento del carico oppure possono applicare policy di sicurezza.
  • Codice su richiesta - Possiamo inviare il codice che estende la funzionalità del client, ad esempio il codice javascript a un browser. Questo è l'unico vincolo facoltativo di REST.

REST webservice - SOAP RPC webservice difference

Quindi un webservice REST è molto diverso da un servizio web SOAP (con stile di binding RPC e stile di codifica letterale)

  • Definisce un'interfaccia uniforme (intestazione di un protocollo).
  • Mappa gli URL alle risorse (e non alle operazioni).
  • Invia messaggi con qualsiasi tipo MIME (anziché solo SOAP + XML).
  • Ha una comunicazione senza stato e quindi non può avere una memoria di sessione lato server. (SOAP non ha vincoli a riguardo)
  • Serve hypermedia e i clienti utilizzano i collegamenti contenuti da quell'ipermedia per richiedere il servizio. (SOAP RPC utilizza le associazioni operative descritte nel file WSDL)
  • Non si interrompe in base alle modifiche dell'URL solo per le modifiche semantiche. (I client RPC SOAP senza utilizzare la semantica RDF interrompono le modifiche ai file WSDL.)
  • È scalabile meglio di un servizio web SOAP a causa del suo comportamento stateless.

e così via...

Un webservice RPC SOAP non soddisfa tutti i vincoli REST:

  • architettura client-server - sempre
  • senza stato - possible
  • cache - possible
  • interfaccia uniforme - mai
  • sistema a strati - possible
  • codice su richiesta (opzionale) - possibile

RIPOSO

Capisco che l'idea principale di REST sia estremamente semplice. Abbiamo usato i browser web per anni e abbiamo visto quanto siano semplici, flessibili, performanti, ecc. I siti HTML utilizzano collegamenti ipertestuali e moduli come mezzo principale di interazione dell'utente. Il loro obiettivo principale è consentire a noi, clienti, di conoscere solo i collegamenti che possiamo utilizzare nello stato attuale . E REST dice semplicemente "perché non utilizzare gli stessi principi per guidare il computer piuttosto che i clienti umani attraverso la nostra applicazione?" Combina questo con la potenza dell'infrastruttura WWW e otterrai uno strumento killer per la creazione di grandi applicazioni distribuite.

Un'altra possibile spiegazione è per le persone che pensano matematicamente. Ogni applicazione è fondamentalmente una macchina a stati con azioni di logica aziendale come transizioni di stato. L'idea di REST consiste nel mappare ogni transizione su una richiesta a una risorsa e fornire ai client collegamenti che rappresentano le transizioni disponibili nello stato corrente. Così modella la macchina a stati tramite rappresentazioni e collegamenti. Questo è il motivo per cui si chiama REpresentational State Transfer.

È abbastanza sorprendente che tutte le risposte sembrino focalizzarsi sul formato del messaggio o sull'uso dei verbi HTTP. In effetti, il formato del messaggio non ha alcuna importanza, REST può usare qualunque a condizione che lo sviluppatore del servizio lo documenti. I verbi HTTP rendono un servizio solo un servizio CRUD, ma non ancora RESTful. Ciò che trasforma realmente un servizio in un servizio REST sono i collegamenti ipertestuali (ovvero i controlli ipermediali) incorporati nelle risposte del server insieme ai dati e la loro quantità deve essere sufficiente per consentire a qualsiasi cliente di scegliere l'azione successiva da tali collegamenti.

Sfortunatamente, è piuttosto difficile trovare informazioni corrette su REST sul Web, fatta eccezione per la ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm . (È quello che ha ottenuto REST). Consiglierei il libro 'REST in Practice' in quanto fornisce un tutorial dettagliato passo-passo su come evolvere da SOAP a REST.

SAPONE

Questa è una delle possibili forme di stile di architettura RPC (chiamata a procedura remota). In sostanza, è solo una tecnologia che consente ai client di chiamare i metodi del server attraverso i confini del servizio (rete, processi, ecc.) Come se stessero chiamando metodi locali. Certo, in realtà differisce dal chiamare metodi locali in velocità, affidabilità e così via, ma l'idea è così semplice.

Rispetto

I dettagli come i protocolli di trasporto, i formati dei messaggi, xsd, wsdl, ecc. Non sono importanti quando si confronta qualsiasi forma di RPC con REST. La differenza principale è che un servizio RPC reinventa la bicicletta progettando il proprio protocollo applicativo nell'API RPC con la semantica che solo lui conosce. Pertanto, tutti i client devono comprendere questo protocollo prima di utilizzare il servizio e nessuna infrastruttura generica come le cache può essere costruita a causa della semantica proprietaria di tutte le richieste. Inoltre, le API RPC non suggeriscono quali azioni sono consentite nello stato corrente, ciò deve essere derivato da documentazione aggiuntiva. REST d'altra parte implica l'utilizzo di interfacce uniformi per consentire a vari client di avere una certa comprensione della semantica API e dei controlli ipermediali (link) per evidenziare le opzioni disponibili in ogni stato. In questo modo, consente di memorizzare le risposte nella cache per scalare i servizi e rendere l'utilizzo dell'API corretto facilmente individuabile senza ulteriore documentazione.

In un certo senso, SOAP (come qualsiasi altro RPC) è un tentativo di attraversare un confine di servizio che tratta i media di connessione come una scatola nera in grado di trasmettere solo messaggi. REST è una decisione per riconoscere che il Web è un enorme sistema informativo distribuito, per accettare il mondo così com'è e imparare a dominarlo invece di combatterlo.

SOAP sembra essere ottimo per le API di rete interne, quando controlli sia il server che i client e mentre le interazioni non sono troppo complesse. È più naturale per gli sviluppatori utilizzarlo. Tuttavia, per un'API pubblica utilizzata da molte parti indipendenti, è complessa e grande, REST dovrebbe adattarsi meglio. Ma quest'ultimo confronto è molto sfocato.

Aggiornare

La mia esperienza ha inaspettatamente dimostrato che lo sviluppo di REST è più difficile di SOAP. Almeno per .NET. Mentre esistono ottimi framework come l'API Web ASP.NET, non ci sono strumenti che generano automaticamente proxy lato client. Niente come 'Aggiungi riferimento servizio Web' o 'Aggiungi riferimento servizio WCF'. Si deve scrivere tutta la serializzazione e il codice di interrogazione del servizio a mano. E amico, questo è un gran numero di codice. Penso che lo sviluppo REST abbia bisogno di qualcosa di simile a WSDL e implementazione di strumenti per ogni piattaforma di sviluppo. In realtà, sembra esserci un buon terreno: WADL o WSDL 2.0 , ma nessuno degli standard sembra essere ben supportato.

Aggiornamento (gennaio 2016)

È venuto fuori che ora esiste una vasta gamma di strumenti per la definizione dell'API REST. La mia preferenza personale è attualmente RAML .

Come funzionano i servizi Web

Bene, questa è una domanda troppo ampia, perché dipende dall'architettura e dalla tecnologia utilizzate nel servizio web specifico. Ma in generale, un servizio web è semplicemente un'applicazione nel Web che può accettare richieste dai clienti e restituire risposte. È esposto al Web, quindi è un servizio Web ed è generalmente disponibile 24 ore su 24, 7 giorni su 7, ecco perché è un servizio . Certo, risolve alcuni problemi (altrimenti perché qualcuno dovrebbe mai utilizzare un servizio web) per i propri clienti.


SOAP - Simple Object Access Protocol è un protocollo !

REST - Il trasferimento dello stato rappresentativo è uno stile architettonico !

SOAP è un protocollo XML utilizzato per trasferire messaggi, in genere su HTTP

REST e SOAP non si escludono a vicenda. Un'architettura RESTful potrebbe utilizzare HTTP o SOAP o qualche altro protocollo di comunicazione. REST è ottimizzato per il web e quindi HTTP è una scelta perfetta. HTTP è anche l' unico protocollo discusso nel documento di Roy Fielding.

Sebbene REST e SOAP siano chiaramente molto diversi, la domanda chiarisce il fatto che REST e HTTP sono spesso usati in tandem. Ciò è dovuto principalmente alla semplicità di HTTP e alla sua mappatura molto naturale ai principi RESTful.

Principi fondamentali di REST

Comunicazione client-server

Le architetture client-server hanno una netta separazione delle preoccupazioni. Tutte le applicazioni costruite nello stile RESTful devono anche essere client-server in modalità princple.

apolide

Ogni richiesta del client al server richiede che il suo stato sia pienamente rappresentato. Il server deve essere in grado di comprendere completamente la richiesta del client senza utilizzare il contesto del server o lo stato della sessione del server. Ne consegue che tutto lo stato deve essere mantenuto sul client. Discuteremo della rappresentanza degli apolidi più in dettaglio più avanti.

cacheable

È possibile utilizzare i vincoli di cache, consentendo in tal modo di contrassegnare i dati di risposta come memorizzabili nella cache o non memorizzabili. Qualsiasi dato contrassegnato come memorizzabile nella cache può essere riutilizzato come risposta alla stessa richiesta successiva.

Interfaccia uniforme

Tutti i componenti devono interagire attraverso un'unica interfaccia uniforme. Poiché l'interazione di tutti i componenti avviene tramite questa interfaccia, l'interazione con diversi servizi è molto semplice. L'interfaccia è la stessa! Ciò significa anche che le modifiche all'implementazione possono essere apportate separatamente. Tali cambiamenti, non influenzeranno l'interazione dei componenti fondamentali perché l'interfaccia uniforme è sempre invariata. Uno svantaggio è che sei bloccato con l'interfaccia. Se è possibile fornire un'ottimizzazione a un servizio specifico modificando l'interfaccia, si è fuori di fortuna poiché REST lo proibisce. Sul lato positivo, tuttavia, REST è ottimizzato per il web, quindi l'incredibile popolarità di REST su HTTP!

I suddetti concetti rappresentano le caratteristiche di definizione di REST e differenziano l'architettura REST da altre architetture come i servizi web. È utile notare che un servizio REST è un servizio Web, ma un servizio Web non è necessariamente un servizio REST.

Vedi questo post sul blog REST Design Principals per maggiori dettagli su REST e sui proiettili sopra indicati.





soap