http - sono - Cos'è esattamente la programmazione RESTful?




web service rest esempio (20)

Cos'è REST?

REST sta per Representational State Transfer. (A volte viene scritto "ReST".) Si basa su un protocollo di comunicazione memorizzabile in cache, client-server, e in quasi tutti i casi viene utilizzato il protocollo HTTP.

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.

In molti modi, il World Wide Web stesso, basato su HTTP, può essere visto come un'architettura basata su REST. Le applicazioni REST utilizzano le richieste HTTP per inviare dati (creare e / o aggiornare), leggere dati (ad esempio, creare query) ed eliminare dati. Pertanto, REST utilizza HTTP per tutte e quattro le operazioni CRUD (Crea / Leggi / Aggiorna / Elimina).

REST è un'alternativa leggera a meccanismi come RPC (Remote Procedure Calls) e Web Services (SOAP, WSDL, ecc.). Più avanti vedremo quanto è più semplice il REST.

Nonostante sia semplice, REST è completo; non c'è praticamente nulla che puoi fare nei servizi Web che non può essere fatto con un'architettura RESTful. REST non è uno "standard". Ad esempio, non ci sarà mai una raccomandazione del W3C per REST. E mentre ci sono i framework di programmazione REST, lavorare con REST è così semplice che spesso è possibile "rollare il proprio" con funzionalità di libreria standard in linguaggi come Perl, Java o C #.

Uno dei migliori riferimenti che ho trovato quando cerco di trovare il semplice significato reale di riposo.

http://rest.elkstein.org/

Cos'è esattamente la programmazione RESTful?


REST è uno stile architettonico basato sugli standard web e il protocollo HTTP (introdotto nel 2000).

In un'architettura basata su REST, tutto è una risorsa (Utenti, Ordini, Commenti). Si accede a una risorsa tramite un'interfaccia comune basata sui metodi standard HTTP (GET, PUT, PATCH, DELETE ecc.).

In un'architettura basata su REST si dispone di un server REST che fornisce l'accesso alle risorse. Un client REST può accedere e modificare le risorse REST.

Ogni risorsa dovrebbe supportare le operazioni comuni HTTP. Le risorse sono identificate da ID globali (che sono in genere URI).

REST consente alle risorse di avere rappresentazioni diverse, ad esempio testo, XML, JSON, ecc. Il client REST può richiedere una rappresentazione specifica tramite il protocollo HTTP (negoziazione del contenuto).

Metodi HTTP:

I metodi PUT, GET, POST e DELETE sono tipici utilizzati nelle architetture basate su REST. La seguente tabella fornisce una spiegazione di queste operazioni.

  • GET definisce un accesso di lettura della risorsa senza effetti collaterali. La risorsa non viene mai modificata tramite una richiesta GET, ad esempio, la richiesta non ha effetti collaterali (idempotente).
  • PUT crea una nuova risorsa. Deve anche essere idempotente.
  • DELETE rimuove le risorse. Le operazioni sono idempotenti. Possono essere ripetuti senza portare a risultati diversi.
  • POST aggiorna una risorsa esistente o crea una nuova risorsa.

Cos'è REST?

Resto in parole ufficiali, REST è uno stile architettonico costruito su alcuni principi che utilizzano gli attuali fondamentali "Web". Ci sono 5 fondamentali di base del web che sono sfruttati per creare servizi REST.

  • Principio 1: Tutto è una risorsa Nello stile architettonico REST, i dati e le funzionalità sono considerati risorse e sono accessibili tramite URI (Uniform Resource Identifiers), in genere collegamenti sul Web.
  • Principio 2: ogni risorsa è identificata da un identificativo univoco (URI)
  • Principio 3: utilizzare interfacce semplici e uniformi
  • Principio 4: la comunicazione è eseguita per rappresentazione
  • Principio 5: essere apolidi

Direi che la programmazione RESTful riguarderà la creazione di sistemi (API) che seguono lo stile architettonico REST.

Ho trovato questo fantastico, breve e facile da capire tutorial su REST di Dr. M. Elkstein e citando la parte essenziale che avrebbe risposto alla tua domanda per la maggior parte:

http://rest.elkstein.org/

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.

  • In molti modi, il World Wide Web stesso, basato su HTTP, può essere visto come un'architettura basata su REST.

Le applicazioni REST utilizzano le richieste HTTP per inviare dati (creare e / o aggiornare), leggere dati (ad esempio, creare query) ed eliminare dati. Pertanto, REST utilizza HTTP per tutte e quattro le operazioni CRUD (Crea / Leggi / Aggiorna / Elimina).

Non penso che dovresti sentirti stupido per non aver sentito parlare di REST al di fuori dello ..., sarei nella stessa situazione !; risposte a questa altra domanda SO su Perché REST sta diventando grande ora potrebbe attenuare alcuni sentimenti.


La risposta è molto semplice, c'è una dissertazione scritta da Roy Fielding. 1 In quella dissertazione definisce i principi REST. Se un'applicazione soddisfa tutti questi principi, allora questa è un'applicazione REST.

roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven Dopo di ciò, anche il termine RESTful era esaurito. Oggigiorno stiamo parlando di API Web e API Hypermedia , perché la maggior parte delle cosiddette applicazioni REST non soddisfacevano la parte HATEOAS del vincolo di interfaccia uniforme.

I vincoli REST sono i seguenti:

  1. architettura client-server

    Quindi non funziona con ad esempio i socket PUB / SUB, è basato su REQ / REP.

  2. comunicazione senza stato

    Quindi il server non mantiene gli stati dei client. Ciò significa che non è possibile utilizzare il server per l'archiviazione della sessione laterale e che è necessario autenticare ogni richiesta. I tuoi clienti possono inviare intestazioni di autenticazione di base tramite una connessione crittografata. (Con le applicazioni di grandi dimensioni è difficile mantenere molte sessioni.)

  3. uso della cache se puoi

    Quindi non devi servire più volte le stesse richieste.

  4. interfaccia uniforme come contratto comune tra client e server

    Il contratto tra il client e il server non viene gestito dal server. In altre parole, il cliente deve essere disaccoppiato dall'implementazione del servizio. È possibile raggiungere questo stato utilizzando soluzioni standard, come lo standard IRI (URI) per identificare le risorse, lo standard HTTP per lo scambio di messaggi, i tipi MIME standard per descrivere il formato di serializzazione del corpo, i metadati (possibilmente vocabri RDF, microformati, ecc.) descrivere la semantica delle diverse parti del corpo del messaggio. Per disaccoppiare la struttura IRI dal client, devi inviare collegamenti ipertestuali ai client in formati ipermediali come (HTML, JSON-LD, HAL, ecc.). Così un cliente può utilizzare i metadati (possibilmente relazioni di collegamento, vocaboli RDF) assegnati ai collegamenti ipertestuali per navigare nella macchina a stati dell'applicazione attraverso le transizioni di stato appropriate al fine di raggiungere il suo obiettivo attuale.

    Ad esempio, quando un cliente desidera inviare un ordine a un negozio online, deve controllare i collegamenti ipertestuali nelle risposte inviate dal negozio online. Controllando i collegamenti ne trova uno descritto con http://schema.org/OrderAction . Il client conosce il vocabolario di schema.org, quindi capisce che attivando questo collegamento ipertestuale invierà l'ordine. Quindi attiva il collegamento ipertestuale e invia un messaggio POST https://example.com/api/v1/order con il corpo corretto. Successivamente il servizio elabora il messaggio e risponde con il risultato che ha l'intestazione corretta dello stato HTTP, ad esempio 201 - created dal successo. Annotare i messaggi con metadati dettagliati la soluzione standard per utilizzare un formato RDF, ad esempio JSON-LD con un vocabolario REST, ad esempio Hydra e vocab di dominio specifici come schema.org o qualsiasi altro vocab di dati collegati e magari un vocabolario specifico dell'applicazione personalizzata se necessario. Ora questo non è facile, ecco perché la maggior parte dei ppl usa HAL e altri semplici formati che di solito forniscono solo un vocabolario REST, ma nessun supporto per i dati collegati.

  5. costruire un sistema a strati per aumentare la scalabilità

    Il sistema REST è composto da livelli gerarchici. Ogni livello contiene componenti che utilizzano i servizi di componenti che si trovano nel livello successivo. Quindi puoi aggiungere nuovi livelli e componenti senza sforzo.

    Ad esempio c'è un livello client che contiene i client e sotto c'è un livello di servizio che contiene un singolo servizio. Ora è possibile aggiungere una cache lato client tra di loro. Successivamente è possibile aggiungere un'altra istanza di servizio e un servizio di bilanciamento del carico, e così via ... Il codice client e il codice di servizio non cambieranno.

  6. codice su richiesta per estendere la funzionalità del client

    Questo vincolo è facoltativo. Ad esempio puoi inviare un parser per un tipo di media specifico al client, e così via ... Per fare questo potresti aver bisogno di un sistema di caricatore di plugin standard nel client, o il tuo client sarà accoppiato alla soluzione del caricatore di plugin .

I vincoli REST risultano in un sistema altamente scalabile in cui i client sono disaccoppiati dalle implementazioni dei servizi. Quindi i client possono essere riutilizzabili, in generale, proprio come i browser sul web. I clienti e i servizi condividono gli stessi standard e vocab, quindi possono capirsi a vicenda nonostante il cliente non conosca i dettagli di implementazione del servizio. Ciò rende possibile creare clienti automatizzati che possono trovare e utilizzare i servizi REST per raggiungere i loro obiettivi.A lungo termine questi clienti possono comunicare tra loro e fidarsi l'uno dell'altro con compiti, proprio come fanno gli umani. Se aggiungiamo modelli di apprendimento a tali client, il risultato sarà uno o più AI che utilizzano il web delle macchine invece di un singolo server park. Quindi alla fine il sogno di Berners Lee: il web semantico e l'intelligenza artificiale saranno realtà. Quindi nel 2030 finiamo con lo Skynet. Fino ad allora ... ;-)


Mi scuso se non rispondo direttamente alla domanda, ma è più facile capire tutto questo con esempi più dettagliati. Fielding non è facile da capire a causa di tutta l'astrazione e la terminologia.

C'è un buon esempio qui:

Spiegazione di REST e Hypertext: Spam-E il robot per la pulizia dello spam

E ancora meglio, c'è una spiegazione chiara con esempi semplici qui (il powerpoint è più completo, ma è possibile ottenerne la maggior parte nella versione html):

http://www.xfront.com/REST.ppt o http://www.xfront.com/REST.html

Dopo aver letto gli esempi, ho potuto capire perché Ken sta dicendo che REST è guidato da un ipertesto. In realtà non sono sicuro che abbia ragione, perché / user / 123 è un URI che punta a una risorsa, e non mi è chiaro che è unRESTful solo perché il client lo sa "out-of-band".

Questo documento di xfront spiega la differenza tra REST e SOAP, e anche questo è molto utile. Quando Fielding dice " roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven ", è chiaro che RPC non è RESTful, quindi è utile vedere le ragioni esatte per questo. (SOAP è un tipo di RPC.)


REST utilizza i vari metodi HTTP (principalmente GET / PUT / DELETE) per manipolare i dati.

Anziché utilizzare un URL specifico per eliminare un metodo (ad esempio /user/123/delete ), si invierà una richiesta DELETE all'URL /user/[id] , per modificare un utente, per recuperare le informazioni su un utente che si invia una richiesta GET a /user/[id]

Ad esempio, invece un insieme di URL che potrebbero apparire come alcuni dei seguenti ...

GET /delete_user.x?id=123
GET /user/delete
GET /new_user.x
GET /user/new
GET /user?id=1
GET /user/id/1

Usi i "verbi" HTTP e hai ...

GET /user/2
DELETE /user/2
PUT /user

Un ottimo libro su REST è REST in Practice .

È necessario leggere che ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm e le roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

Vedi l'articolo di Martin Fowlers sul Richardson Maturity Model (RMM) per una spiegazione su cosa sia un servizio RESTful.

Per essere RESTful un servizio deve soddisfare l' ipermedia come il motore dello stato dell'applicazione. (HATEOAS) , cioè deve raggiungere il livello 3 nell'RMM, leggere l'articolo per i dettagli o le diapositive del qcon talk .

Il vincolo HATEOAS è l'acronimo di Hypermedia come Engine of Application State. Questo principio è il principale elemento di differenziazione tra un REST e la maggior parte delle altre forme di sistema client server.

...

Un client di un'applicazione RESTful deve solo conoscere un singolo URL fisso per accedervi. Tutte le azioni future dovrebbero essere rilevabili in modo dinamico dai collegamenti ipermediali inclusi nelle rappresentazioni delle risorse restituite da tale URL. Ci si aspetta che anche i tipi di media standardizzati siano compresi da qualsiasi client che possa utilizzare un'API RESTful. (Da Wikipedia, l'enciclopedia libera)

REST Test Litmus per Web Framework è un test di maturità simile per i framework web.

Approccio al puro REST: imparare ad amare HATEOAS è una buona raccolta di link.

REST contro SOAP per Public Cloud discute gli attuali livelli di utilizzo di REST.

REST e versioning discutono di estensibilità, versioning, evolvibilità, ecc. Tramite modificabilità


RESTful programmazione API RESTful (Representational state transfer) sta scrivendo applicazioni web in qualsiasi linguaggio di programmazione seguendo 5 principi di base dello stile architettonico del software :

  1. Risorsa (dati, informazioni).
  2. Identificatore globale univoco (tutte le risorse sono identificate in modo univoco URI ).
  3. Interfaccia uniforme : usa l' interfaccia semplice e standard (HTTP).
  4. Rappresentazione: tutte le comunicazioni vengono eseguite mediante la rappresentazione (ad es. XML / JSON )
  5. Stateless (ogni richiesta avviene in completo isolamento, è più facile memorizzare e bilanciare il carico),

In altre parole, stai scrivendo semplici applicazioni di rete point-to-point su HTTP che usano verbi come GET, POST, PUT o DELETE implementando l'architettura RESTful che propone la standardizzazione dell'interfaccia che ogni "risorsa" espone. Non è niente che usi le funzionalità attuali del web in modo semplice ed efficace (architettura di successo, collaudata e distribuita). È un'alternativa a meccanismi più complessi come SOAP , CORBA e RPC .

La programmazione RESTful è conforme alla progettazione dell'architettura Web e, se correttamente implementata, consente di sfruttare appieno l'infrastruttura Web scalabile.


Parlare è più che semplicemente scambiare informazioni . Un protocollo è in realtà progettato in modo tale che non si debba parlare. Ogni parte sa qual è il loro particolare lavoro perché è specificato nel protocollo. I protocolli consentono lo scambio di informazioni puri a scapito di eventuali cambiamenti nelle possibili azioni. Parlare, d'altra parte, consente a una parte di chiedere quali ulteriori azioni possono essere prese dall'altra parte. Possono anche fare la stessa domanda due volte e ottenere due risposte diverse, poiché lo stato dell'altra parte potrebbe essere cambiato nel frattempo. Parlare è un'architettura RESTful . La tesi di Fielding specifica l'architettura che si dovrebbe seguire se si volesse consentire alle macchine di comunicare tra loro piuttosto che semplicementecomunicare .


Che cos'è il test API ?

Il test API utilizza la programmazione per inviare chiamate all'API e ottenere il rendimento. Il test riguarda il segmento in prova come una scatola nera. L'obiettivo del test API è quello di confermare l'esecuzione corretta e il trattamento errato della parte che precede il suo coordinamento in un'applicazione.

API REST

REST: trasferimento dello stato di rappresentanza.

  • È un insieme di funzioni su cui i tester eseguono le richieste e ricevono le risposte. Nelle interazioni API REST vengono effettuate tramite protocollo HTTP.
  • REST consente inoltre la comunicazione tra computer tra loro su una rete.
  • Per l'invio e la ricezione di messaggi, implica l'utilizzo di metodi HTTP e non richiede una definizione rigorosa dei messaggi, a differenza dei servizi Web.
  • I messaggi REST accettano spesso il modulo in forma di XML o JavaScript Object Notation (JSON).

4 metodi API comunemente usati: -

  1. RICEVERE: - Fornisce accesso di sola lettura a una risorsa.
  2. POST: - È usato per creare o aggiornare una nuova risorsa.
  3. PUT: - Viene utilizzato per aggiornare o sostituire una risorsa esistente o creare una nuova risorsa.
  4. CANCELLA: - Viene utilizzato per rimuovere una risorsa.

Passi per testare manualmente l'API: -

Per utilizzare manualmente le API, possiamo utilizzare plug-in API REST basati su browser.

  1. Installa il plugin POSTMAN (Chrome) / REST (Firefox)
  2. Inserisci l'URL dell'API
  3. Seleziona il metodo REST
  4. Seleziona contenuto-Intestazione
  5. Inserisci richiesta JSON (POST)
  6. Clicca su invia
  7. Restituirà la risposta in uscita

Passi per automatizzare l'API REST


REST sta per trasferimento dello stato di rappresentanza .

Si basa su un protocollo di comunicazione memorizzabile da zero, client-server, e in quasi tutti i casi, viene utilizzato il protocollo HTTP.

REST viene spesso utilizzato in applicazioni mobili, siti Web di social networking, strumenti di mashup e processi aziendali automatizzati. Lo stile REST sottolinea che le interazioni tra client e servizi sono migliorate con un numero limitato di operazioni (verbi). La flessibilità è fornita dall'assegnazione di risorse (nomi) ai loro unici indicatori di risorse universali (URI).

Introduzione sul riposo


Questa è una "discussione" incredibilmente lunga e tuttavia abbastanza confusa, per non dire altro.

IMO:

1) Non esiste una cosa come una programmazione riposante, senza un grosso giunto e molta birra :)

2) Representational State Transfer (REST) ​​è uno stile architettonico specificato nella tesi di Roy Fielding . Ha una serie di vincoli. Se il tuo Servizio / Cliente rispetta quelli, allora è RESTful. Questo è.

È possibile riepilogare (significativamente) i vincoli a:

  • comunicazione senza stato
  • rispetta le specifiche HTTP (se viene usato HTTP)
  • comunica chiaramente i formati di contenuti trasmessi
  • usa hypermedia come motore dello stato dell'applicazione

C'è un altro roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven che spiega le cose bene.

Un sacco di risposte copiano / incollano informazioni valide mescolandole e aggiungendo un po 'di confusione. Le persone parlano dei livelli, degli URI RESTFul (non esiste una cosa del genere!), Applicano i metodi HTTP GET, POST, PUT ... REST non si tratta di questo o di non solo.

Ad esempio i collegamenti: è bello avere un'API dall'aspetto magnifico, ma alla fine il client / server non si preoccupa veramente dei collegamenti che ottieni / invia è il contenuto che conta.

Alla fine ogni cliente RESTful dovrebbe essere in grado di consumare qualsiasi servizio RESTful purché sia ​​noto il formato del contenuto.


REST è uno stile di architettura software di sistemi distribuiti (come WWW), si può immaginare che si tratti di regole di applicazione Web ben progettate: un gruppo di pagine Web Internet (una macchina a stati virtuali), in cui collegamento ipertestuale facendo clic sul collegamento (transizione stato ), il risultato è la prossima pagina Web (che indica lo stato successivo dell'applicazione).

REST descrive il sistema di rete costituito da tre parti:

  1. elementi di dati (risorsa, identificatore di risorsa, rappresentazione)
  2. connettori (client, server, cache, resolver, tunnel)
  3. componenti (server di origine, gateway, proxy, programma utente)

REST rispetta rigorosamente le seguenti condizioni:

  1. Lo stato della funzionalità dell'applicazione è suddiviso in risorse
  2. Ogni risorsa utilizzata come sintassi di posizionamento dei collegamenti ipertestuali (ad esempio, nell'URI WWW)
  3. Tutte le risorse condividono un'interfaccia uniforme tra il client e lo stato di transizione della risorsa, tra cui:
    1. Un insieme limitato di operazioni ben definite (cioè in HTTP GET / POST / PUT / DELETE)
    2. Un insieme limitato di tipi di contenuto in formato contenuto, che possono includere codice eseguibile (ad esempio, nel Javascript WWW)

Uno stile architettonico denominato REST (Representational State Transfer) sostiene che le applicazioni Web dovrebbero utilizzare HTTP come era stato originariamente previsto . Le ricerche devono utilizzare le richieste GET . GET devono essere utilizzate rispettivamente per la mutazione, la creazione e la cancellazione .

I sostenitori di REST tendono a favorire gli URL, come ad esempio

http://myserver.com/catalog/item/1729

ma l'architettura REST non richiede questi "pretty URL". Una richiesta GET con un parametro

http://myserver.com/catalog?item=1729

è altrettanto riposante.

Tieni presente che le richieste GET non dovrebbero mai essere utilizzate per l'aggiornamento delle informazioni. Ad esempio, una richiesta GET per aggiungere un articolo a un carrello

http://myserver.com/addToCart?cart=314159&item=1729

non sarebbe appropriato Le richieste GET dovrebbero essere idempotent . Cioè, l'emissione di una richiesta due volte non dovrebbe essere diversa dall'emissione di una volta. Questo è ciò che rende le richieste memorizzabili nella cache. Una richiesta "aggiungi al carrello" non è idempotente: emettendola due volte aggiunge due copie dell'articolo al carrello. Una richiesta POST è chiaramente appropriata in questo contesto. Pertanto, anche un'applicazione web RESTful necessita della sua condivisione di richieste POST.

Questo è tratto dal libro eccellente Core JavaServer affronta il libro di David M. Geary.


Ecco il mio schema di base di REST. Ho cercato di dimostrare il pensiero dietro ognuno dei componenti in un'architettura RESTful in modo che la comprensione del concetto fosse più intuitiva. Speriamo che questo aiuti a demistificare REST per alcune persone!

REST (Representational State Transfer) è un'architettura di progettazione che descrive come sono progettate e indirizzate le risorse in rete (ovvero i nodi che condividono le informazioni). In generale, un'architettura RESTful fa in modo che il client (la macchina richiedente) e il server (la macchina rispondente) possano richiedere di leggere, scrivere e aggiornare i dati senza che il client debba sapere come funziona il server e il server può passare torna indietro senza bisogno di sapere nulla del cliente. Ok, bello ... ma come lo facciamo in pratica?

  • Il requisito più ovvio è che ci sia bisogno di un linguaggio universale di qualche tipo in modo che il server possa dire al client cosa sta cercando di fare con la richiesta e il server a rispondere.

  • Ma per trovare una data risorsa e poi dire al cliente dove vive quella risorsa, ci deve essere un modo universale di puntare alle risorse. È qui che entrano gli URI (Universal Resource Identifiers); sono fondamentalmente indirizzi univoci per trovare le risorse.

Ma l'architettura REST non finisce qui! Mentre sopra soddisfa i bisogni di base di ciò che vogliamo, vogliamo anche avere un'architettura che supporti il ​​traffico ad alto volume dal momento che ogni dato server di solito gestisce le risposte da un numero di client. Pertanto, non vogliamo sommergere il server facendogli ricordare informazioni sulle richieste precedenti.

  • Pertanto, imponiamo la restrizione che ogni coppia richiesta-risposta tra il client e il server sia indipendente, il che significa che il server non deve ricordare nulla delle precedenti richieste (stati precedenti dell'interazione client-server) per rispondere a una nuova richiesta. Ciò significa che vogliamo che le nostre interazioni siano apolidi.

  • Per facilitare ulteriormente lo sforzo sul nostro server di ripetere i calcoli che sono già stati effettuati di recente per un determinato client, REST consente anche il caching. Fondamentalmente, il caching significa scattare un'istantanea della risposta iniziale fornita al cliente. Se il client esegue nuovamente la stessa richiesta, il server può fornire al client lo snapshot anziché ripetere tutti i calcoli necessari per creare la risposta iniziale. Tuttavia, poiché è un'istantanea, se lo snapshot non è scaduto, il server imposta in anticipo una data di scadenza e la risposta è stata aggiornata dalla cache iniziale (ovvero la richiesta fornirebbe una risposta diversa rispetto alla risposta memorizzata nella cache) , il client non vedrà gli aggiornamenti fino alla scadenza della cache (o alla cancellazione della cache) e la risposta verrà nuovamente eseguita da zero.

  • L'ultima cosa che vedrai spesso riguardo le architetture RESTful è che sono sovrapposte. In realtà abbiamo già discusso implicitamente di questo requisito nella nostra discussione sull'interazione tra client e server. Fondamentalmente, questo significa che ogni livello nel nostro sistema interagisce solo con livelli adiacenti. Pertanto, nella nostra discussione, il livello client interagisce con il nostro livello server (e viceversa), ma potrebbero esserci altri livelli server che aiutano il server primario a elaborare una richiesta con cui il client non comunica direttamente. Piuttosto, il server trasmette la richiesta secondo necessità.

Ora, se tutto ciò suona familiare, allora fantastico. L'Hypertext Transfer Protocol (HTTP), che definisce il protocollo di comunicazione tramite il World Wide Web, è un'implementazione della nozione astratta di architettura RESTful (o un'istanza della classe REST se sei un fanatico di OOP come me). In questa implementazione di REST, client e server interagiscono tramite GET, POST, PUT, DELETE, ecc., Che fanno parte del linguaggio universale e le risorse possono essere indirizzate all'utilizzo di URL.


Penso che il punto di riposo sia la separazione dello stato in uno strato superiore mentre si utilizza Internet (protocollo) come uno strato di trasporto senza stato . La maggior parte degli altri approcci mescola le cose.

È stato il miglior approccio pratico per gestire i cambiamenti fondamentali della programmazione nell'era di Internet. Riguardo ai cambiamenti fondamentali, Erik Meijer ha una discussione in mostra qui: http://www.infoq.com/interviews/erik-meijer-programming-language-design-effects-purity#view_93197 . Lo riassume come i cinque effetti e presenta una soluzione progettando la soluzione in un linguaggio di programmazione. La soluzione potrebbe anche essere raggiunta a livello di piattaforma o di sistema, indipendentemente dalla lingua. Il riposante potrebbe essere visto come una delle soluzioni che ha avuto molto successo nella pratica corrente.

Con uno stile rilassante, ottieni e manipola lo stato dell'applicazione su un Internet inaffidabile. Se fallisce l'operazione corrente per ottenere lo stato corretto e attuale, ha bisogno del principio di convalida zero per aiutare l'applicazione a continuare. Se non riesce a manipolare lo stato, di solito utilizza più fasi di conferma per mantenere le cose corrette. In questo senso, il riposo non è di per sé una soluzione completa, ha bisogno delle funzioni in altre parti dello stack di applicazioni Web per supportare il suo funzionamento.

Dato questo punto di vista, lo stile di riposo non è realmente legato a Internet o all'applicazione web. È una soluzione fondamentale per molte delle situazioni di programmazione. Non è nemmeno semplice, ma rende l'interfaccia davvero semplice e affronta incredibilmente bene altre tecnologie.

Solo il mio 2c.

Modifica: due aspetti più importanti:


Questo è molto meno menzionato ovunque, ma il modello di maturità di Richardson è uno dei migliori metodi per giudicare effettivamente quanto Restful sia la propria API. Maggiori informazioni qui:

Richardson's Maturity Model


REST === L'analogia HTTP non è corretta finché non si sottolinea il fatto che "DEVE" essere guidato da HATEOAS .

Roy stesso lo ha chiarito roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven .

Un'API REST deve essere inserita senza alcuna conoscenza preliminare oltre l'URI iniziale (segnalibro) e set di tipi di supporti standardizzati appropriati per il pubblico previsto (vale a dire, dovrebbero essere compresi da qualsiasi client che potrebbe utilizzare l'API). Da quel momento in poi, tutte le transizioni dello stato dell'applicazione devono essere guidate dalla selezione dei client delle scelte fornite dal server presenti nelle rappresentazioni ricevute o implicite dalla manipolazione dell'utente di tali rappresentazioni. Le transizioni possono essere determinate (o limitate dalla) conoscenza da parte del cliente dei tipi di media e dei meccanismi di comunicazione delle risorse, entrambi possono essere migliorati al volo (ad esempio, code-on-demand).

[Il fallimento qui implica che le informazioni fuori banda stanno guidando l'interazione invece dell'ipertesto.]






definition