Share
Hypertext Transfer Protocol (HTTP) è la vita del web. Viene utilizzato ogni volta che si trasferisce un documento o si crea un AJAX richiesta. Ma HTTP è sorprendentemente un parente sconosciuto tra alcuni sviluppatori web.
Questa introduzione dimostrerà come l'insieme di principi di progettazione, noto come REST, sottostà a HTTP e consente di sfruttare appieno la propria potenza costruendo interfacce, che possono essere utilizzate praticamente da qualsiasi dispositivo o sistema operativo.
Envato Market ha anche migliaia di utili script di codice, plugin e app per aiutarti con lo sviluppo web, come HTTP Assistant, un'app che ti aiuta a testare i servizi web online.
L'app Assistente HTTP su Envato Market Tutorial ripubblicato Ogni poche settimane, rivisitiamo alcuni dei post preferiti dei nostri lettori da tutta la storia del sito. Questo tutorial è stato pubblicato per la prima volta nel novembre 2010.
REST è un modo semplice per organizzare interazioni tra sistemi indipendenti.
REST è un modo semplice per organizzare interazioni tra sistemi indipendenti. Cresce in popolarità dal 2005 e ispira la progettazione di servizi, come l'API di Twitter. Ciò è dovuto al fatto che REST consente di interagire con un sovraccarico minimo con client diversi come telefoni cellulari e altri siti Web. In teoria, REST non è legato al web, ma è quasi sempre implementato come tale ed è stato ispirato da HTTP. Di conseguenza, REST può essere utilizzato ovunque sia HTTP.
L'alternativa è la costruzione di convenzioni relativamente complesse su HTTP. Spesso, questo prende la forma di interi nuovi linguaggi basati su XML. L'esempio più illustre è SOAP. Devi imparare una nuova serie di convenzioni, ma non usi mai l'HTTP alla massima potenza. Poiché REST è stato ispirato da HTTP e gioca ai suoi punti di forza, è il modo migliore per imparare come funziona HTTP.
Dopo una panoramica iniziale, esamineremo ciascuno dei blocchi predefiniti HTTP: URL, verbi HTTP e codici di risposta. Esamineremo anche come usarli in modo RESTful. Lungo la strada, illustreremo la teoria con un'applicazione di esempio, che simula il processo di tenere traccia dei dati relativi ai clienti di un'azienda attraverso un'interfaccia web.
HTTP è il protocollo che consente di inviare documenti avanti e indietro sul web.
HTTP è il protocollo che consente di inviare documenti avanti e indietro sul web. Un protocollo è un insieme di regole che determina quali messaggi possono essere scambiati e quali messaggi sono risposte appropriate agli altri. Un altro protocollo comune è POP3, che è possibile utilizzare per recuperare e-mail sul disco rigido.
In HTTP, ci sono due ruoli diversi: server e client. In generale, il client inizia sempre la conversazione; il server risponde HTTP è basato sul testo; cioè, i messaggi sono essenzialmente bit di testo, sebbene il corpo del messaggio possa contenere anche altri media. L'utilizzo del testo facilita il monitoraggio di uno scambio HTTP.
I messaggi HTTP sono fatti di un'intestazione e di un corpo. Il corpo può spesso rimanere vuoto; contiene dati che si desidera trasmettere attraverso la rete, al fine di usarli secondo le istruzioni nell'intestazione. L'intestazione contiene metadati, come le informazioni di codifica; ma, nel caso di una richiesta, contiene anche i metodi HTTP importanti. Nello stile REST, troverai che i dati di intestazione sono spesso più significativi del corpo.
Se utilizzi Chrome Developer Tools o Firefox con l'estensione Firebug installata, fai clic su Netto pannello e impostarlo su abilitato. Avrai quindi la possibilità di visualizzare i dettagli delle richieste HTTP mentre navighi. Per esempio:
Un altro modo utile per familiarizzare con HTTP è utilizzare un client dedicato, come ad esempio cURL.
cURL è uno strumento da riga di comando disponibile su tutti i principali sistemi operativi.
Una volta installato cURL, digita:
arricciare -v google.com
Questo mostrerà la conversazione HTTP completa. Le richieste sono precedute da >, mentre le risposte sono precedute da <.
Gli URL sono il modo in cui identifichi le cose su cui vuoi operare. Diciamo che ogni URL identifica una risorsa. Questi sono esattamente gli stessi URL che sono assegnati alle pagine web. In effetti, una pagina web è un tipo di risorsa. Facciamo un esempio più esotico e consideriamo la nostra applicazione di esempio, che gestisce l'elenco dei clienti di un'azienda:
/ clienti
identificherà tutti i client, mentre
/ Client / jim
identificherà il cliente, denominato "Jim", assumendo che sia l'unico con quel nome.
In questi esempi, in genere non includiamo il nome host nell'URL, in quanto è irrilevante dal punto di vista dell'organizzazione dell'interfaccia. Tuttavia, il nome host è importante per garantire che l'identificativo della risorsa sia unico in tutto il web. Spesso diciamo che hai inviato la richiesta per una risorsa a un ospite. L'host è incluso nell'intestazione separatamente dal percorso della risorsa, che si trova direttamente sopra l'intestazione della richiesta:
GET / clients / jim Host HTTP / 1.1: esempio.com
Le risorse sono meglio pensate come nomi. Ad esempio, il seguente non è RESTful:
/ clienti / aggiungi
Questo perché utilizza un URL per descrivere un'azione. Questo è un punto abbastanza fondamentale per distinguere RESTful dai sistemi non RESTful.
Infine, gli URL dovrebbero essere tanto precisi quanto necessario; tutto ciò che è necessario per identificare in modo univoco una risorsa dovrebbe essere nell'URL. Non è necessario includere i dati che identificano la risorsa nella richiesta. In questo modo, gli URL fungono da una mappa completa di tutti i dati gestiti dalla tua applicazione.
Ma come si specifica un'azione? Ad esempio, come si dice che si desidera creare un nuovo record client anziché recuperato? È qui che entrano in gioco i verbi HTTP.
Ogni richiesta specifica un determinato verbo HTTP, o metodo, nell'intestazione della richiesta. Questa è la prima parola tutte maiuscole nell'intestazione della richiesta. Per esempio,
GET / HTTP / 1.1
significa che il metodo GET è in uso, mentre
DELETE / clients / anne HTTP / 1.1
significa il ELIMINA metodo è in uso.
I verbi HTTP dicono al server cosa fare con i dati identificati dall'URL.
I verbi HTTP dicono al server cosa fare con i dati identificati dall'URL. La richiesta può facoltativamente contenere informazioni aggiuntive nel suo corpo, che potrebbero essere richieste per eseguire l'operazione, ad esempio i dati che si desidera archiviare con la risorsa. È possibile fornire questi dati in cURL con il -d opzione.
Se hai mai creato moduli HTML, avrai familiarità con due dei verbi HTTP più importanti: OTTENERE e INVIARE. Ma ci sono molti più verbi HTTP disponibili. I più importanti per la creazione di API RESTful sono OTTENERE, INVIARE, METTERE e ELIMINA. Sono disponibili altri metodi, come CAPO e OPZIONI, ma sono più rari (se vuoi sapere su tutti gli altri metodi HTTP, la fonte ufficiale è IETF).
OTTENERE è il tipo più semplice di metodo di richiesta HTTP; quello che i browser utilizzano ogni volta che fai clic su un link o digita un URL nella barra degli indirizzi. Indica al server di trasmettere i dati identificati dall'URL al client. I dati non dovrebbero mai essere modificati sul lato server come risultato di a OTTENERE richiesta. In questo senso, a OTTENERE la richiesta è di sola lettura, ma ovviamente, una volta che il client riceve i dati, è libero di fare qualsiasi operazione con esso dal proprio lato - ad esempio, formattarlo per la visualizzazione.
UN METTERE la richiesta viene utilizzata quando si desidera creare o aggiornare la risorsa identificata dall'URL. Per esempio,
PUT / clienti / pettirosso
potrebbe creare un client, chiamato pettirosso sul server. Lo noterai RIPOSO è completamente indipendente dal backend; non c'è nulla nella richiesta che informa il server su come devono essere creati i dati, solo che dovrebbe. Ciò consente di scambiare facilmente la tecnologia back-end in caso di necessità. METTERE le richieste contengono i dati da utilizzare nell'aggiornamento o nella creazione della risorsa nel corpo. In cURL, puoi aggiungere dati alla richiesta con -d interruttore.
curl -v -X PUT -d "some text"
ELIMINA dovrebbe eseguire il contrario di METTERE; dovrebbe essere usato quando si desidera eliminare la risorsa identificata dall'URL della richiesta.
curl -v -X DELETE / clients / anne
Questo cancellerà tutti i dati associati alla risorsa, identificati da / Client / anne.
INVIARE viene utilizzato quando l'elaborazione che si desidera eseguire sul server deve essere ripetuta, se il INVIARE la richiesta viene ripetuta (cioè, non lo sono idempotente; più su quello sotto). Inoltre, INVIARE le richieste dovrebbero causare l'elaborazione del corpo della richiesta come subordinato dell'URL in cui stai postando.
In parole povere:
POST / clienti /
non dovrebbe causare la risorsa a / clienti /, stesso, da modificare, ma una risorsa il cui URL inizia con /client /. Ad esempio, potrebbe aggiungere un nuovo client all'elenco, con un id generato dal server.
/ Client / some-unico-id
METTERE le richieste sono usate facilmente invece di INVIARE richieste e viceversa. Alcuni sistemi ne usano solo uno, alcuni usano INVIARE per creare operazioni, e METTERE per le operazioni di aggiornamento (poiché con a METTERE richiesta di fornire sempre l'URL completo), alcuni addirittura utilizzano INVIARE per aggiornamenti e METTERE per crea.
Spesso, INVIARE le richieste vengono utilizzate per attivare le operazioni sul server, che non si adattano al Crea / aggiornamento / eliminazione paradigma; ma questo, tuttavia, va oltre lo scopo di RIPOSO. Nel nostro esempio, continueremo a farlo METTERE fino.
Accentsconagua
OTTENERE. Gli altri non sono sicuri, perché potrebbero comportare una modifica delle risorse. Metodi idempotenti: Questi metodi ottengono lo stesso risultato, non importa quante volte la richiesta viene ripetuta: lo sono OTTENERE, METTERE, e ELIMINA. L'unico metodo non idempotente è INVIARE. METTERE e ELIMINA essere considerato idempotente potrebbe essere sorprendente, tuttavia, in realtà, è abbastanza facile da spiegare: ripetere a METTERE il metodo con esattamente lo stesso corpo dovrebbe modificare una risorsa in modo che rimanga identica a quella descritta nella precedente METTERE richiesta: nulla cambierà! Allo stesso modo, non ha senso cancellare una risorsa due volte. Ne consegue che non importa quante volte a METTERE o ELIMINA la richiesta viene ripetuta, il risultato dovrebbe essere lo stesso come se fosse stato eseguito una sola volta. Ricorda: sei tu, il programmatore, che alla fine decide cosa succede quando viene usato un determinato metodo HTTP. Non c'è nulla di intrinseco alle implementazioni HTTP che causeranno automaticamente la creazione, l'elencazione, l'eliminazione o l'aggiornamento delle risorse. Devi stare attento ad applicare correttamente il protocollo HTTP e applicare da solo queste semantiche.
Il client HTTP e il server HTTP scambiano informazioni sulle risorse identificate dagli URL.
Possiamo riassumere ciò che abbiamo imparato finora nel modo seguente: il client HTTP e il server HTTP scambiano informazioni sulle risorse identificate dagli URL.
Diciamo che la richiesta e la risposta contengono una rappresentazione della risorsa. Per rappresentazione, si intende l'informazione, in un determinato formato, sullo stato della risorsa o su come dovrebbe essere lo stato in futuro. Sia l'intestazione che il corpo sono pezzi della rappresentazione.
Le intestazioni HTTP, che contengono metadati, sono strettamente definite dalla specifica HTTP; possono contenere solo testo semplice e devono essere formattati in un determinato modo.
Il corpo può contenere dati in qualsiasi formato, ed è qui che la potenza di HTTP brilla davvero. Sai che puoi inviare testo semplice, immagini, HTML e XML in qualsiasi linguaggio umano. Attraverso i metadati della richiesta o diversi URL, puoi scegliere tra diverse rappresentazioni per la stessa risorsa. Ad esempio, è possibile inviare una pagina Web ai browser e JSON alle applicazioni.
La risposta HTTP dovrebbe specificare il tipo di contenuto del corpo. Questo è fatto nell'intestazione, nel Tipo di contenuto campo; per esempio:
Contenuto / Tipo: application / json
Per semplicità, la nostra applicazione di esempio invia solo JSON avanti e indietro, ma l'applicazione dovrebbe essere architetturata in modo tale che sia possibile modificare facilmente il formato dei dati, adattarli a client diversi o preferenze utente.
cURL è, il più delle volte, la soluzione client HTTP di scelta per gli sviluppatori PHP.
Per sperimentare i diversi metodi di richiesta, è necessario un client, che consente di specificare quale metodo utilizzare. Sfortunatamente, i moduli HTML non si adattano alla fattura, in quanto consentono solo di effettuare richieste GET e POST. Nella vita reale, le API sono accessibili a livello di programmazione tramite un'applicazione client separata o tramite JavaScript nel browser.
Questo è il motivo per cui, oltre al server, è essenziale disporre di buone capacità del client HTTP disponibili nel linguaggio di programmazione prescelto.
Una libreria client HTTP molto popolare è, ancora, cURL. Hai già familiarizzato con il comando cURL di prima in questo tutorial. cURL include sia un programma a riga di comando indipendente che una libreria che può essere utilizzata da vari linguaggi di programmazione. In particolare, cURL è, il più delle volte, la soluzione client HTTP di scelta per gli sviluppatori PHP. Altre lingue, come Python, offrono più librerie client native native.
Voglio esporre quanto più possibile le funzionalità di basso livello.
La nostra applicazione PHP di esempio è estremamente ridotta. Voglio esporre la funzionalità di basso livello il più possibile, senza alcuna magia di struttura. Inoltre, non volevo utilizzare una vera API, come quella di Twitter, perché sono soggette a modifiche inaspettate, è necessario impostare l'autenticazione, che può essere una seccatura e, ovviamente, non è possibile studiare l'implementazione.
Per eseguire l'applicazione di esempio, è necessario installare PHP5 e un server Web, con alcuni meccanismi per eseguire PHP. La versione corrente deve essere almeno della versione 5.2 per avere accesso a json_encode () e json_decode () funzioni.
Per quanto riguarda i server, la scelta più comune è ancora Apache mod_php, ma sei libero di usare qualsiasi alternativa con cui ti trovi bene. Esiste una configurazione Apache di esempio, che contiene regole di riscrittura per aiutarti a configurare rapidamente l'applicazione. Tutte le richieste a qualsiasi URL, a partire da / clients /, devono essere indirizzate al nostro server.php file.
In Apache, è necessario abilitare mod_rewrite e metti il fornito mod_rewrite configurazione da qualche parte nella configurazione di Apache o nel tuo .htacess file. Per di qua, server.php risponderà a tutte le richieste provenienti dal server. Lo stesso deve essere ottenuto con Nginx, o qualsiasi altro server alternativo tu decida di utilizzare.
Ci sono due chiavi per l'elaborazione delle richieste nel modo REST. La prima chiave è avviare un'elaborazione diversa, in base al metodo HTTP, anche quando gli URL sono uguali. In PHP, c'è una variabile nel $ _SERVER array globale, che determina quale metodo è stato utilizzato per effettuare la richiesta:
$ _SERVER [ 'REQUEST_METHOD']
Questa variabile contiene il nome del metodo come una stringa, ad esempio 'OTTENERE','METTERE', e così via.
L'altra chiave è sapere quale URL è stato richiesto. Per fare ciò, usiamo un'altra variabile PHP standard:
$ _SERVER [ 'REQUEST_URI']
Questa variabile contiene l'URL a partire dalla prima barra in avanti. Ad esempio, se il nome host è 'example.com','http://example.com/'ritornerebbe'/', mentre 'http://example.com/test/'ritornerebbe'/test/'.
Proviamo innanzitutto a determinare quale URL è stato chiamato. Prendiamo in considerazione solo gli URL che iniziano con 'clienti'. Tutti gli altri non sono validi.
$ resource = array_shift ($ percorsi); if ($ resource == 'clients') $ name = array_shift ($ percorsi); if (vuoto ($ nome)) $ this-> handle_base ($ method); else $ this-> handle_name ($ method, $ name); else // Gestiamo solo le risorse sotto l'intestazione 'clients' ('HTTP / 1.1 404 Not Found'); Abbiamo due possibili risultati:
Se c'è un ulteriore identificatore, assumiamo che sia il nome del cliente, e, ancora una volta, lo inoltriamo a una funzione diversa, a seconda della metodo. Noi usiamo a interruttore affermazione, che dovrebbe essere evitata in un'applicazione reale:
switch ($ method) case 'PUT': $ this-> create_contact ($ name); rompere; caso 'DELETE': $ this-> delete_contact ($ name); rompere; case 'GET': $ this-> display_contact ($ name); rompere; default: header ('HTTP / 1.1 405 Method Not Allowed'); header ('Allow: GET, PUT, DELETE'); rompere; I codici di risposta HTTP standardizzano un modo di informare il cliente sul risultato della sua richiesta.
Potresti aver notato che l'applicazione di esempio utilizza il PHP intestazione(), passare alcune strane stringhe come argomenti. Il intestazione() la funzione stampa il HTTP intestazioni e assicura che siano formattati in modo appropriato. Le intestazioni dovrebbero essere la prima cosa nella risposta, quindi non dovresti produrre altro prima di aver terminato le intestazioni. A volte, il tuo server HTTP può essere configurato per aggiungere altre intestazioni, oltre a quelle specificate nel codice.
Le intestazioni contengono tutti i tipi di meta informazioni; ad esempio, la codifica del testo utilizzata nel corpo del messaggio o il tipo MIME del contenuto del corpo. In questo caso, stiamo specificando esplicitamente i codici di risposta HTTP. I codici di risposta HTTP standardizzano un modo di informare il cliente sul risultato della sua richiesta. Di default, PHP restituisce a 200 codice di risposta, il che significa che la risposta ha esito positivo.
Il server dovrebbe restituire il codice di risposta HTTP più appropriato; in questo modo, il cliente può tentare di riparare i suoi errori, supponendo che ce ne siano. La maggior parte delle persone ha familiarità con il comune 404 non trovato codice di risposta, tuttavia, ci sono molti più disponibili per adattarsi a un'ampia varietà di situazioni.
Tieni presente che il significato di un codice di risposta HTTP non è estremamente preciso; questa è una conseguenza del fatto che HTTP stesso sia piuttosto generico. Dovresti tentare di usare il codice di risposta che corrisponde più strettamente alla situazione attuale. Detto questo, non ti preoccupare troppo se non riesci a trovare una misura esatta.
Ecco alcuni codici di risposta HTTP, che vengono spesso utilizzati con REST:
Questo codice di risposta indica che la richiesta è stata eseguita correttamente.
Ciò indica che la richiesta è stata eseguita correttamente e che è stata creata una risorsa. È usato per confermare il successo di a METTERE o INVIARE richiesta.
La richiesta era malformata. Questo succede specialmente con INVIARE e METTERE richieste, quando i dati non superano la convalida o sono nel formato sbagliato.
Questa risposta indica che non è stato possibile trovare la risorsa richiesta. Questo è generalmente restituito a tutte le richieste che puntano a un URL senza risorse corrispondenti.
Questo errore indica che è necessario eseguire l'autenticazione prima di accedere alla risorsa.
Il metodo HTTP utilizzato non è supportato per questa risorsa.
Questo indica un conflitto. Ad esempio, stai utilizzando un METTERE richiesta di creare la stessa risorsa due volte.
Quando tutto il resto fallisce; generalmente, viene utilizzata una risposta 500 quando l'elaborazione non riesce a causa di circostanze impreviste sul lato server, che causa l'errore del server.
Iniziamo semplicemente recuperando le informazioni dall'applicazione. Vogliamo i dettagli del cliente 'jim', quindi inviamo un semplice OTTENERE richiesta all'URL per questa risorsa:
curl -v http: // localhost: 80 / clients / jim
Questo mostrerà l'intestazione completa del messaggio. L'ultima riga nella risposta sarà il corpo del messaggio; in questo caso, sarà JSON contenente l'indirizzo di Jim (ricorda che l'omissione di un nome di metodo comporterà a OTTENERE richiesta; anche sostituire localhost: 80 con il nome del server e la porta che stai usando).
Successivamente, possiamo ottenere le informazioni per tutti i clienti contemporaneamente:
curl -v http: // localhost: 80 / clients /
Per creare un nuovo client, denominato Paul ...
curl -v -X PUT http: // localhost: 80 / clients / paul -d '"address": "Sunset Boulevard"
e riceverai la lista di tutti i clienti che ora contengono Paul come conferma.
Infine, per eliminare un cliente:
curl -v -X DELETE http: // localhost: 80 / clients / anne
Scoprirai che il JSON restituito non contiene più alcun dato su Anne.
Se si tenta di recuperare un client non esistente, ad esempio:
curl -v http: // localhost: 80 / clients / jerry
Otterrai un errore 404, mentre, se tenti di creare un client già esistente:
curl -v -X PUT http: // localhost: 80 / clients / anne
Riceverete invece un errore 409.
In generale, meno presupposti oltre l'HTTP che fai, meglio è.
È importante ricordare che HTTP è stato concepito per comunicare tra sistemi, che non condividono nient'altro che una comprensione del protocollo. In generale, meno ipotesi assunte al di là di HTTP, meglio è: questo consente alla più ampia gamma di programmi e dispositivi di accedere alla tua API.
Ho usato PHP in questo tutorial, perché è molto probabilmente la lingua più familiare ai lettori di Nettuts. Detto questo, PHP, sebbene sia progettato per il web, probabilmente non è la lingua migliore da usare quando si lavora in modalità REST, poiché gestisce METTERE richieste in modo completamente diverso da OTTENERE e INVIARE.
Oltre PHP, potresti considerare quanto segue:
Tra le applicazioni che tentano di aderire ai principi REST, l'esempio classico è l'Atom Publishing Protocol, anche se in pratica non viene usato troppo spesso nella pratica. Per un'applicazione moderna, basata sulla filosofia dell'uso di HTTP al massimo, fare riferimento a Apache CouchDB.
E non dimenticare di controllare la selezione di script di codice, plugin e app su Envato Market.
Divertiti!
Abbiamo creato una guida completa per aiutarti a imparare JavaScript, sia che tu stia appena iniziando come sviluppatore web o che desideri esplorare argomenti più avanzati.
