Comprensione di Internet senza stato [chiuso]

Sto passando da uno sviluppatore desktop a uno sviluppatore web e ho difficoltà a capire perché HTTP sia apolide. Quali sono le ragioni? Quali sono alcuni modi in cui uno sviluppatore desktop come me può effettuare il passaggio a un ambiente di sviluppo senza stato?

Questa è la migliore spiegazione di Internet senza stato che ho visto:

Come ho spiegato REST  a My Wife
http://www.looah.com/source/view/2284

Moglie: chi è Roy Fielding?

Ryan: Qualcuno. Lui è intelligente.

Moglie: Oh? Cosa ha fatto?

Ryan: Ha aiutato a scrivere i primi web server e poi ha fatto molte ricerche per spiegare perché il web funziona così. Il suo nome è nelle specifiche del protocollo utilizzato per ottenere pagine dai server al browser.

Moglie: come funziona?

Ryan: Il web?

Moglie: Sì.

Ryan: Hmm. Bene, è davvero davvero fantastico. E la cosa divertente è che è tutto molto sottovalutato. Il protocollo di cui parlavo, HTTP, è capace di ogni sorta di roba ordinata che la gente ignora per qualche motivo.

Moglie: Intendi http come l'inizio di ciò che scrivo nel browser?

Ryan: Sì. Quella prima parte indica al browser quale protocollo utilizzare. Quelle cose che scrivi lì sono una delle scoperte più importanti nella storia dell'informatica.

Moglie: Perché?

Ryan: Perché è in grado di descrivere la posizione di qualcosa in qualsiasi parte del mondo da qualsiasi parte del mondo. È il fondamento del web. Puoi pensarlo come coordinate GPS per conoscenza e informazioni.

Moglie: per le pagine Web?

Ryan: Per davvero. Quel ragazzo, Roy Fielding, parla molto di ciò che indicano quelle cose in quella ricerca di cui stavo parlando. Il web è costruito su uno stile architettonico chiamato REST. REST fornisce una definizione di una risorsa, che è ciò che queste cose indicano.

Moglie: una pagina web è una risorsa?

Ryan: Un po '. Una pagina Web è una rappresentazione di una risorsa. Le risorse sono solo concetti. URL: quelle cose che digiti nel browser ...

Moglie: so cos'è un URL ..

Ryan: Oh, giusto. Questi dicono al browser che esiste un concetto da qualche parte. Un browser può quindi chiedere una rappresentazione specifica del concetto. In particolare, il browser richiede la rappresentazione della pagina Web del concetto.

Moglie: quali altri tipi di rappresentazioni ci sono?

Ryan: In realtà, le rappresentazioni sono una di queste cose che non si abituano molto. Nella maggior parte dei casi, una risorsa ha una sola rappresentazione. Ma speriamo che le rappresentazioni vengano utilizzate più in futuro perché ci sono un sacco di nuovi formati che spuntano ovunque.

Moglie: come cosa?

Ryan: Hmm. Bene, c'è questo concetto che le persone chiamano i servizi Web. Significa molte cose diverse per molte persone diverse, ma il concetto di base è che le macchine potrebbero usare il web proprio come fanno le persone.

Moglie: è un'altra cosa robot?

Ryan: No, non proprio. Non voglio dire che le macchine siedano alla scrivania e navighino sul web. Ma i computer possono usare quegli stessi protocolli per inviare messaggi avanti e indietro. Lo facciamo da molto tempo, ma nessuna delle tecniche che usiamo oggi funziona bene quando devi essere in grado di parlare con tutte le macchine di tutto il mondo.

Moglie: Perché no?

Ryan: Perché non sono stati progettati per essere usati così. Quando Fielding e i suoi amici hanno iniziato a costruire la rete, essere in grado di parlare con qualsiasi macchina in qualsiasi parte del mondo era una preoccupazione primaria. La maggior parte delle tecniche che usiamo al lavoro per convincere i computer a parlare tra loro non aveva questi requisiti. Dovevi solo parlare con un piccolo gruppo di macchine.

Moglie: E ora devi parlare con tutte le macchine?

Ryan: Sì - e altro ancora. Dobbiamo essere in grado di parlare con tutte le macchine di tutto ciò che è presente su tutte le altre macchine. Quindi abbiamo bisogno di un modo per far dire a una macchina un'altra macchina su una risorsa che potrebbe trovarsi su un'altra macchina.

Moglie: cosa?

Ryan: Diciamo che stai parlando con tua sorella e lei vuole prendere in prestito lo spazzino o qualcosa del genere. Ma tu non ce l'hai - tua mamma ce l'ha. Quindi dici a tua sorella di prenderlo invece da tua madre. Questo succede sempre nella vita reale e succede sempre quando anche le macchine iniziano a parlare.

Moglie: Allora, come fanno le macchine a dirsi dove sono le cose?

Ryan: L'URL, ovviamente. Se tutto ciò di cui le macchine devono parlare ha un URL corrispondente, hai creato l'equivalente macchina di un sostantivo. Che tu ed io e il resto del mondo abbiamo concordato di parlare dei sostantivi in ​​un certo modo è piuttosto importante, eh?

Moglie: Sì.

Ryan: Le macchine non hanno un nome universale - ecco perché fanno schifo. Ogni linguaggio di programmazione, database o altro tipo di sistema ha un modo diverso di parlare dei nomi. Ecco perché l'URL è così importante. Permettono a tutti questi sistemi di raccontarsi l'un l'altro dei nomi degli altri.

Moglie: Ma quando guardo una pagina web, non la penso così.

Ryan: Nessuno lo fa. Tranne Fielding e una manciata di altre persone. Ecco perché le macchine fanno ancora schifo.

Moglie: Che dire di verbi, pronomi e aggettivi?

Ryan: Divertente che mi hai chiesto perché è un altro aspetto importante di REST. Bene, i verbi lo sono comunque.

Moglie: stavo solo scherzando.

Ryan: Era uno scherzo divertente ma in realtà non è affatto uno scherzo. I verbi sono importanti. C'è un concetto potente nella programmazione e nella teoria CS chiamato polimorfismo. È un modo geniale di dire che nomi diversi possono avere lo stesso verbo applicato a loro.

Moglie: Non capisco.

Ryan: Beh ... guarda il tavolino. Quali sono i nomi? Tazza, vassoio, giornale, telecomando. Ora, quali sono alcune cose che puoi fare per tutte queste cose?

Moglie: Non capisco ...

Ryan: Puoi prenderli, giusto? Puoi raccoglierli. Puoi rovesciarli. Puoi bruciarli. Puoi applicare gli stessi verbi esatti a qualsiasi oggetto seduto lì.

Moglie: Okay ... quindi?

Ryan: Beh, è ​​importante. E se invece di essere in grado di dirti "prendi la tazza", "prendi il giornale" e "prendi il telecomando"; e se invece avessimo bisogno di elaborare verbi diversi per ciascuno dei nomi? Non ho potuto usare la parola "get" universalmente, ma invece ho dovuto inventare una nuova parola per ogni combinazione verbo / sostantivo.

Moglie: Wow! Quello è strano.

Ryan: Sì, lo è. Il nostro cervello è in qualche modo abbastanza intelligente da sapere che gli stessi verbi possono essere applicati a molti nomi diversi. Alcuni verbi sono più specifici di altri e si applicano solo a un piccolo set di nomi. Ad esempio, non posso guidare una tazza e non posso bere una macchina. Ma alcuni verbi sono quasi universali come GET, PUT e DELETE.

Moglie: non puoi ELIMINARE una tazza.

Ryan: Bene, okay, ma puoi buttarlo via. Era un'altra battuta, vero?

Moglie: Sì.

Ryan: Comunque, HTTP - questo protocollo creato da Fielding e dai suoi amici - riguarda l'applicazione dei verbi ai nomi. Ad esempio, quando si accede a una pagina Web, il browser esegue un HTTP GET sull'URL digitato e viceversa arriva una pagina Web.

Le pagine Web di solito contengono immagini, giusto? Quelle sono risorse separate. La pagina Web specifica solo gli URL delle immagini e il browser passa e fa più HTTP GET su di esse fino a quando non vengono ottenute tutte le risorse e viene visualizzata la pagina Web. Ma la cosa importante qui è che tipi di nomi molto diversi possono essere trattati allo stesso modo. Se il nome è un'immagine, un testo, un video, un mp3, una presentazione o altro. Posso ottenere tutte queste cose allo stesso modo dato un URL.

Moglie: Sembra che GET sia un verbo piuttosto importante.

Ryan: Lo è. Soprattutto quando si utilizza un browser Web perché i browser sono praticamente cose di JustGET. Non fanno molti altri tipi di interazione con le risorse. Questo è un problema perché ha portato molte persone a supporre che HTTP sia solo per OTTENERE. Ma HTTP è in realtà un protocollo di scopo generale per l'applicazione dei verbi ai nomi.

Moglie: fantastica. Ma ancora non vedo come questo cambi qualcosa. Che tipo di nomi e verbi vuoi?

Ryan: Beh, i sostantivi sono lì ma non nel formato giusto.

Pensa a quando navighi su amazon.com alla ricerca di cose da comprarmi per Natale. Immagina ciascuno dei prodotti come nomi. Ora, se fossero disponibili in una rappresentazione che una macchina potesse capire, potresti fare molte cose pulite.

Moglie: Perché una macchina non può capire una normale pagina Web?

Ryan: Perché le pagine Web sono progettate per essere comprese dalle persone. A una macchina non interessa il layout e lo stile. Le macchine praticamente hanno solo bisogno dei dati. Idealmente, ogni URL avrebbe una rappresentazione leggibile dall'uomo e una lettura leggibile dalla macchina. Quando una macchina OTTIENE la risorsa, chiederà quella leggibile dalla macchina. Quando un browser OTTIENE una risorsa per un essere umano, chiederà quello leggibile dall'uomo.

Moglie: Quindi le persone dovrebbero creare formati macchina per tutte le loro pagine?

Ryan: Se fosse prezioso.

Senti, ne abbiamo parlato con molta astrazione. Che ne dici di prendere un esempio reale. Sei un insegnante - a scuola scommetto che hai un grande sistema informatico, o tre o quattro sistemi informatici più probabili, che ti consentono di gestire gli studenti: in che classe frequentano, in che classe stanno ricevendo, contatti di emergenza, informazioni sui libri a cui insegnate, ecc. Se i sistemi sono basati sul web, allora probabilmente c'è un URL per ciascuno dei nomi coinvolti qui: studente, insegnante, classe, libro, stanza, ecc. In questo momento, ottenere l'URL il browser ti dà una pagina web. Se esistesse una rappresentazione leggibile automaticamente per ciascun URL, sarebbe banale agganciare nuovi strumenti al sistema perché tutte quelle informazioni sarebbero consumabili in modo standard. Inoltre renderebbe un po 'più semplice la conversazione tra i vari sistemi. Oppure, potresti costruire un sistema statale o nazionale in grado di parlare con ciascuno dei singoli sistemi scolastici per raccogliere i punteggi dei test. Le possibilità sono infinite.

Ciascuno dei sistemi otterrebbe informazioni l'uno dall'altro utilizzando un semplice HTTP GET. Se un sistema deve aggiungere qualcosa a un altro sistema, utilizza un POST HTTP. Se un sistema desidera aggiornare qualcosa in un altro sistema, utilizza un HTTP PUT. L'unica cosa che resta da capire è come dovrebbero apparire i dati.

Moglie: Quindi questo è ciò su cui tu e tutti i computer state lavorando ora? Decidi come dovrebbero apparire i dati?

Ryan: Purtroppo no. Invece, la grande maggioranza è impegnata a scrivere livelli di specifiche complesse per fare queste cose in un modo diverso che non è altrettanto utile o eloquente. I sostantivi non sono universali e i verbi non sono polimorfici. Stiamo buttando via decenni di utilizzo reale sul campo e tecniche collaudate e ricominciando da capo con qualcosa che assomiglia molto ad altri sistemi che hanno fallito in passato. Stiamo usando HTTP ma solo perché ci aiuta a parlare di meno con la nostra rete e con le persone della sicurezza. Stiamo scambiando semplicità con strumenti e maghi appariscenti.

Moglie: Perché?

Ryan: Non ne ho idea.

Moglie: Perché non dici qualcosa?

Ryan: Forse lo farò.

Come pensi che sarebbe possibile memorizzare lo stato di miliardi di miliardi di miliardi di miliardi di connessioni? :) Quindi memorizzi lo stato solo dove necessario, in sessioni.

A proposito: HTTP non è senza connessione.

Come sviluppatore desktop potresti sentirti più a tuo agio con esperienze utente complete. Passare al Web può sembrare un passo indietro. Nel mondo web c'è meno libertà creativa e può darti un senso di costrizione. Non lasciarti abbattere! Ci sono un certo numero di cose là fuori che possono aiutarti a fare la transizione ed ecco un breve elenco di loro:

1. Lo stato può essere condiviso ma è spesso conservato sul server e referenziato usando token come ID sessione, parametri URL, campi nascosti o valori cookie.
2. I modelli senza stato sono adatti per l'elaborazione delle transazioni. Prova a costruire il tuo modello in modo tale da ridurre la quantità di stato richiesta. I principi ACID dell'elaborazione delle transazioni possono aiutarti a raggiungere questo obiettivo.
3. Acquisire familiarità con il modello MVC (se non lo si è già). Ciò contribuirà a migliorare la progettazione mantenendo una separazione delle preoccupazioni. Alcuni framework popolari come Struts (Java) e MVC (.NET) sono costruiti attorno a questo concetto.
4. Prendi in considerazione l'utilizzo di un plug-in come Java , Flash o Silverlight per esperienze di interfaccia utente super ricche. Per esperienze semi-ricche, prendi in considerazione l'uso delle librerie basate su script java popolari come JQuery o AJAX .

Buona programmazione!

Perché c'era un tempo in cui non c'erano milioni e milioni di pagine web. Perché c'era un tempo in cui solo le università e le strutture di ricerca avevano un paio di pagine. C'è stato un tempo in cui non c'era la banda larga e http veniva comunicato con 1200 modem baud posizionati sopra i telefoni da scrivania. C'è stato un tempo in cui "le app web ricche" avrebbero richiesto, a loro avviso, una quantità ridicola di larghezza di banda. E ricorda, TCP / IP è stato creato perché la prima Internet era molto inaffidabile.

HTTP 1.0 era in circolazione nei primi anni '90. Pensa a come era internet di allora, e perché l'hanno progettata come hanno fatto.

Tutto si è evoluto. Internet esisteva prima dei browser Web e del Web. Era una pentola gorgogliante di ftp, telnet, gopher, ping, finger e qualche altro bit e bob. Il primo browser web, Mosaic (? Penso, è stato molto tempo fa, 1991, penso, ero al college) ha funzionato come una sorta di miscuglio tra ftp e un visualizzatore di documenti. La magia è avvenuta nel fatto che potresti avere dei collegamenti nel documento che potrebbero far apparire un nuovo documento.

Tutta l'interattività che ora abbiamo sviluppato nel corso dei 20 anni seguenti. Non è stata nemmeno una felice evoluzione. Abbiamo avuto le guerre dei browser, IE e Netscape hanno messo a punto il controllo degli standard (Bit of a semplification;)) e varie altre terze parti hanno iniziato a introdurre plug-in per consentire contenuti ricchi. Java sarebbe stato il proiettile magico e ovviamente Flash. Qualcuno ricorda i plug-in VRML che promettevano mondi 3d e fornivano esattamente una mezza dozzina di modelli 3d di modelli di Star Wars?

Sono stato un po 'trascinato verso la fine, ma hai avuto l'idea :)

Le ragioni principali hanno a che fare con una combinazione di ciò che l'acedemia riteneva lo scopo dell'HTTP e per motivi di scalabilità. L'HTML è stato originariamente progettato per condividere informazioni o tesi oltre i confini accademici. Era un testo puramente stilizzato. Fu solo quando il primo browser ti permise di pubblicare immagini che la gente iniziò a pensare oltre quel modello.

Le seguenti considerazioni hanno rafforzato la decisione apolide:

• L'interazione tipica sarebbe stata un download rapido e una lettura. Durante il ritardo fino alla richiesta successiva, il socket rimarrebbe inattivo.
• I socket occupano preziose risorse di sistema. Se non avessimo dovuto mantenere una conversazione come faresti con SMTP, puoi fare molto per avere una macchina in grado di gestire migliaia di client.
• Hanno già imparato preziose lezioni dalla gestione di account shell remoti, NFS, SMTP e altri protocolli di connessione con stato.

Man mano che le pagine Web diventavano più complesse e comprendevano numerosi elementi grafici e fogli di stile, HTTP veniva aggiunto con il flag "keep-alive". Ciò manterrebbe il socket attivo e consentirebbe al client di richiedere diverse risorse con la stessa conversazione.

Considerando l'attuale modello di utilizzo di Internet, la decisione originale è ancora valida. A volte può essere scomodo, ma diverse piccole interazioni quantizzate con un server si ridimensionano meglio dei socket inattivi.

Se intendi i browser bidirezionali.

Ragioni di sicurezza.

Ad esempio SPAM !.

Portare la comunicazione bidirezionale sul Web al livello successivo

Altrimenti Internet esegue TCP / IP (due protocolli) e UDP.

Il protocollo di controllo della trasmissione(TCP) è uno dei protocolli principali di Internet Protocol Suite. TCP è uno dei due componenti originali della suite, a complemento dell'Internet Protocol (IP), e quindi l'intera suite viene comunemente definita TCP / IP. TCP fornisce il servizio di scambio di dati direttamente tra due host sulla stessa rete, mentre l'IP gestisce l'indirizzamento e il routing dei messaggi attraverso una o più reti. In particolare, TCP fornisce la consegna affidabile e ordinata di un flusso di byte da un programma su un computer a un altro programma su un altro computer. TCP è il protocollo su cui si basano le principali applicazioni Internet, applicazioni come il World Wide Web, la posta elettronica e il trasferimento di file. Altre applicazioni, che non richiedono un servizio di flusso di dati affidabile,

Il protocollo Internet(IP) è il principale protocollo di comunicazione utilizzato per l'inoltro di datagrammi (pacchetti) attraverso una rete interna utilizzando Internet Protocol Suite. Responsabile del routing dei pacchetti attraverso i confini della rete, è il protocollo principale che stabilisce Internet. L'IP è il protocollo principale nell'Internet Layer di Internet Protocol Suite e ha il compito di consegnare datagrammi dall'host di origine all'host di destinazione esclusivamente in base ai loro indirizzi. A tale scopo, IP definisce i metodi e le strutture di indirizzamento per l'incapsulamento del datagramma. Storicamente, l'IP era il servizio datagramma senza connessione nel Programma di controllo della trasmissione originale introdotto da Vint Cerf e Bob Kahn nel 1974, l'altro era il TCP (Transmission Control Protocol) orientato alla connessione. Pertanto, Internet Protocol Suite viene spesso definito TCP / IP.

In un'applicazione desktop, si presume che l'utente stia eseguendo alcune serie di attività, con un inizio e una fine definiti. In tale applicazione, ha senso (non molto, in realtà) che gli utenti accedano a qualunque server fornisca i loro dati e rimangano connessi fino al termine.

Le interazioni Web non seguono (in genere) lo stesso modello. In un sito di e-commerce, ad esempio, un utente può arrivare a una descrizione del prodotto come risultato di una ricerca su Google e lasciare immediatamente quella pagina per vedere l'offerta di un altro sito dello stesso prodotto. Oppure potrebbe avviare la procedura di pagamento, quindi decidere che il prodotto è troppo costoso e abbandonarlo a metà. L'idea di base di "ipertesto" implica la capacità e l'aspettativa di saltare da una posizione all'altra.

Le connessioni permanenti consumano risorse. Forse solo un socket di rete, forse un pool di query di database analizzate; tutto dipende dall'applicazione. Dato un utente che può scomparire in qualsiasi momento, non ha molto senso mantenere impegnate tali risorse.

In pratica, non è necessario che l'utente abbia una connessione permanente. L'applicazione Web mantiene le connessioni a qualsiasi risorsa (ad es. Database) di cui ha bisogno e le condivide tra tutte le richieste degli utenti. Il framework delle app Web fornisce sessioni, che sono luoghi a tempo limitato per l'archiviazione dei dati per utente per diverse richieste. L'unica cosa che non puoi fare (facilmente) è avere transazioni controllate da client a lungo termine, ma questa è una cattiva idea anche in un'app che mantiene connessioni.

Internet non è necessariamente apolide - infatti quando si guarda a Java EE - hanno bean Stateful e bean Stateless.

Il motivo principale per cui gli sviluppatori raccomandano di utilizzare un'architettura senza stato è a causa della scalabilità. Immagina di provare a mantenere lo stato di tutti i tuoi utenti dopo aver aggiunto e lasciato cadere i server per supportare il tuo traffico.

Non è davvero difficile sviluppare un'architettura senza stato. Il punto principale è mantenere il minor stato possibile (di solito un ID utente - preferibilmente in un cookie) e modificare il database come richiesto.

Penso che sia iniziato in quel modo e abbia continuato ad esserlo. Ora che c'è così tanta infrastruttura costruita attorno ad essa, è impossibile cambiarla.

Forse è iniziato senza stato perché le connessioni all'inizio erano meno affidabili e anche la larghezza di banda era inferiore. Se non hai molte connessioni attive, puoi gestire più traffico più facilmente.

Modifica o lascia un commento se hai informazioni migliori o, meglio ancora, pubblica la tua risposta!

È perché i server forniscono un servizio (è nel nome). Fai una richiesta e ricevi risposte - tutto qui.

Per quanto riguarda il passaggio allo sviluppo web, credo che ASP.NET Web Forms lo farà in un modo che sarà più comprensibile per te - ma è solo perché nasconde ciò che sta realmente accadendo sotto strati di astrazione.

Molto può essere compreso analizzando il nome di HTTP (HyperText Transfer Protocol). Non è mai stato progettato per essere un protocollo UI ricco. L'idea originale era quella di condividere documenti con collegamenti tra loro. Ti chiedo un documento, tu rispondi con una copia di quel documento.

Inizialmente HTTP aveva un solo verbo GET. A tale proposito, è stato progettato per contenuti statici. Perché hai bisogno di uno stato quando tutto ciò che stai facendo è richiedere un documento che qualcuno sta condividendo? Ed è per questo che HTTP è apolide ... a causa delle sue origini.