Qual è la differenza tra HTTP e REST?

Dopo aver letto molto sulle differenze tra REST e SOAP, ho avuto l'impressione che REST sia solo un'altra parola per HTTP. Qualcuno può spiegare quale funzionalità REST aggiunge a HTTP?

Nota : non sto cercando un confronto tra REST e SOAP.

Aggiornamento : grazie per le risposte. Ora mi è diventato chiaro che REST è solo un insieme di regole su come usare HTTP. Quindi ho pubblicato un seguito su quali sono i vantaggi di queste convenzioni .

Nota : ora capisco il significato di REST; come osserva Emil Ivanov , REST significa usare HTTP come dovrebbe essere. Tuttavia, non sono sicuro che questo meriti un termine a sé stante, e di certo non riesco a ottenere l'hype intorno ad esso.

No, REST è il modo in cui HTTP deve essere usato .

Oggi usiamo solo una piccola parte dei metodi del protocollo HTTP - vale a dire GETe POST. Il modo REST per farlo è usare tutti i metodi del protocollo.

Ad esempio, REST impone l'utilizzo di DELETEcancellare un documento (che si tratti di un file, stato, ecc.) Dietro un URI, mentre, con HTTP, si userebbe in modo improprio un GETo POSTquery simile ...product/?delete_id=22.

HTTP è un protocollo utilizzato per la comunicazione, generalmente utilizzato per comunicare con risorse Internet o qualsiasi applicazione con un client browser web.

REST significa che il concetto principale che si sta utilizzando durante la progettazione dell'applicazione è la Risorsa: per ogni azione che si desidera eseguire è necessario definire una risorsa su cui di solito si fa solo un'operazione CRUD, che è un compito semplice. per questo è molto conveniente usare 4 verbi usati nel protocollo HTTP contro le 4 operazioni CRUD (Get for Read, POST è per CREATE, PUT è per UPDATE e DELETE è per DELETE). questo è diverso dal vecchio concetto di RPC (Remote Procedure Call), in cui hai una serie di azioni che vuoi eseguire come risultato della chiamata dell'utente. se pensi ad esempio a come descrivere un facebook come su un post, con RPC potresti creare servizi chiamati AddLikeToPost e RemoveLikeFromPost e gestirlo insieme a tutti gli altri servizi relativi ai post FB, quindi non dovrai creare speciali oggetto per Like. con REST avrai un oggetto Like che sarà gestito separatamente con le funzioni Elimina e Crea. Significa anche che descriverà un'entità separata nel tuo db. potrebbe sembrare una piccola differenza, ma lavorare così produrrebbe generalmente un codice molto più semplice e un'applicazione molto più semplice. con quel design, la maggior parte della logica dell'app è ovvia dalla struttura (modello) dell'oggetto, a differenza di RPC con cui di solito dovresti aggiungere esplicitamente molta più logica.

progettare un'applicazione RESTful di solito è molto più difficile perché richiede di descrivere cose complicate in modo semplice. descrivere tutte le funzionalità usando solo le funzioni CRUD è complicato, ma dopo averlo fatto la tua vita sarebbe molto più semplice e scoprirai che scriverai metodi molto più brevi.

Un'ulteriore architettura REST presente è quella di non utilizzare il contesto della sessione quando si comunica con il client (senza stato), il che significa che tutte le informazioni necessarie per capire chi è il client e ciò che desidera vengono passate con il messaggio web. ogni chiamata a una funzione è auto-descrittiva, non esiste una conversazione precedente con il client a cui si può fare riferimento nel messaggio. pertanto un cliente non potrebbe dirti "dammi la pagina successiva" poiché non hai una sessione per memorizzare qual è la pagina precedente e che tipo di pagina desideri, il cliente dovrebbe dire "il mio nome è yuval, ottenere io pagina 2 di un post specifico in un forum specifico ". ciò significa che un po 'più di dati dovrebbero essere trasferiti nella comunicazione, ma pensa alla differenza tra la ricerca di un bug segnalato dalla funzione "get me next page" in contrapposizione a "

Naturalmente c'è molto di più, ma secondo me sono i concetti principali in un cucchiaino.

HTTP è un protocollo applicativo. REST è un insieme di regole che, se seguito, consente di creare un'applicazione distribuita con un insieme specifico di vincoli desiderabili.

Se stai cercando i vincoli più significativi di REST che distinguono un'applicazione RESTful da qualsiasi altra applicazione HTTP, direi il vincolo di "auto-descrizione" e il vincolo ipermediale (noto anche come Hypermedia come il motore dello stato dell'applicazione (HATEOAS)) il più importante.

Il vincolo di auto-descrizione richiede che una richiesta RESTful sia completamente auto-descrittiva nelle intenzioni degli utenti. Ciò consente agli intermediari (proxy e cache) di agire sul messaggio in modo sicuro.

Il vincolo HATEOAS consiste nel trasformare l'applicazione in una rete di collegamenti in cui lo stato corrente del client si basa sulla sua posizione in quella rete. È un concetto complicato e richiede più tempo per spiegare di quello che ho in questo momento.

A quanto ho capito, REST impone l'uso dei comandi HTTP disponibili nel modo in cui dovevano essere utilizzati.

Ad esempio, potrei fare:

GET
http://example.com?method=delete&item=xxx

Ma con il resto userei il metodo di richiesta "DELETE", eliminando la necessità del parametro di query "method"

DELETE
http://example.com?item=xxx

Non proprio...

http://en.wikipedia.org/wiki/Representational_State_Transfer

REST è stato inizialmente descritto nel contesto di HTTP, ma non è limitato a quel protocollo. Le architetture RESTful possono essere basate su altri protocolli del livello applicazione se forniscono già un vocabolario ricco e uniforme per le applicazioni basate sul trasferimento di uno stato rappresentativo significativo. Le applicazioni RESTful massimizzano l'uso dell'interfaccia preesistente e ben definita e di altre funzionalità integrate fornite dal protocollo di rete scelto e minimizzano l'aggiunta di nuove funzionalità specifiche dell'applicazione.

http://www.looselycoupled.com/glossary/SOAP

(Simple Object Access Protocol) Lo standard per i messaggi dei servizi Web. Basato su XML, SOAP definisce un formato di busta e varie regole per descriverne il contenuto. Visto (con WSDL e UDDI) come uno dei tre standard di base dei servizi Web, è il protocollo preferito per lo scambio di servizi Web, ma non è l'unico; i sostenitori di REST affermano che aggiunge complessità inutili.

REST è un modo specifico di affrontare la progettazione di grandi sistemi (come il web).

È un insieme di "regole" (o "vincoli").

HTTP è un protocollo che tenta di obbedire a tali regole.

REST = Trasferimento rappresentativo dello stato

REST è un insieme di regole che, se seguito, consente di creare un'applicazione distribuita con un insieme specifico di vincoli desiderabili.

REST è un protocollo per lo scambio di eventuali messaggi (XML, JSON ecc.) Che possono utilizzare HTTP per trasportare tali messaggi.

Caratteristiche:

È senza stato, il che significa che idealmente nessuna connessione dovrebbe essere mantenuta tra il client e il server. È responsabilità del client passare il suo contesto al server e quindi il server può memorizzare questo contesto per elaborare l'ulteriore richiesta del client. Ad esempio, la sessione gestita dal server è identificata dall'identificatore di sessione passato dal client.

Vantaggi dell'apolidia:

1. I servizi Web possono trattare le chiamate di ciascun metodo separatamente.
2. I servizi Web non devono necessariamente mantenere l'interazione precedente del client.
3. Questo a sua volta semplifica la progettazione dell'applicazione.
4. HTTP è esso stesso un protocollo senza stato a differenza di TCP e quindi RESTful Web Services funziona perfettamente con i protocolli HTTP.

Svantaggi dell'apolidia:

1. Un livello aggiuntivo sotto forma di intestazione deve essere aggiunto a ogni richiesta per preservare lo stato del cliente.
2. Per motivi di sicurezza, è necessario aggiungere un'intestazione a ogni richiesta.

Metodi HTTP supportati da REST:

OTTIENI: / string / someotherstring È idempotente e dovrebbe idealmente restituire gli stessi risultati ogni volta che viene effettuata una chiamata

PUT: Come GET. Idempotente e viene utilizzato per aggiornare le risorse.

POST: dovrebbe contenere un url e un body utilizzati per la creazione di risorse. Le chiamate multiple dovrebbero idealmente restituire risultati diversi e dovrebbero creare più prodotti.

ELIMINA: utilizzato per eliminare risorse sul server.

TESTA:

Il metodo HEAD è identico a GET, tranne per il fatto che il server NON DEVE restituire un corpo di messaggio nella risposta. Le meta informazioni contenute nelle intestazioni HTTP in risposta a una richiesta HEAD DOVREBBERO essere identiche alle informazioni inviate in risposta a una richiesta GET.

OPZIONI:

Questo metodo consente al client di determinare le opzioni e / o i requisiti associati a una risorsa o le capacità di un server, senza implicare un'azione di risorse o avviare un recupero delle risorse.

Risposte HTTP

Vai qui per tutte le risposte .

Eccone alcuni importanti: 200 - OK 3XX - Informazioni aggiuntive necessarie dal client e reindirizzamento dell'URL 400 - Richiesta
errata 401 - Non autorizzato ad accedere
403 - Proibito
La richiesta era valida, ma il server rifiuta l'azione. L'utente potrebbe non disporre delle autorizzazioni necessarie per una risorsa o potrebbe essere necessario un account di qualche tipo.

404 - Non trovato
La risorsa richiesta non è stata trovata ma potrebbe essere disponibile in futuro. Sono consentite richieste successive da parte del cliente.

405 - Metodo non consentito Un metodo di richiesta non è supportato per la risorsa richiesta; ad esempio, una richiesta GET su un modulo che richiede la presentazione di dati tramite POST o una richiesta PUT su una risorsa di sola lettura.

404 - Richiesta non trovata
500 - Errore interno del server
502 - Errore gateway non valido

HTTP è un protocollo di comunicazione che trasporta i messaggi su una rete. SOAP è un protocollo per lo scambio di messaggi basati su XML che può utilizzare HTTP per trasportare tali messaggi. Rest è un protocollo per scambiare qualsiasi messaggio (XML o JSON) che può usare HTTP per trasportare quei messaggi.

HTTP is a contract, a communication protocol and REST is a concept, an architectural style che può utilizzare HTTP, FTP o altri protocolli di comunicazione ma è ampiamente utilizzato con HTTP.

REST implies a series of constraints about how Server and Client should interact. HTTP is a communication protocol with a given mechanism for server-client data transfer, viene utilizzato più comunemente nell'API REST solo perché REST was inspired by WWW (world wide web) which largely used HTTPprima della definizione di REST, quindi è più semplice implementare lo stile API REST con HTTP.

There are three major constraints in REST (but there are more):

1. L'interazione tra server e client deve essere descritta solo tramite ipertesto.

2.Server e client dovrebbero essere liberamente accoppiati e non fare ipotesi l'uno sull'altro. Il client dovrebbe conoscere solo il punto di ingresso delle risorse. I dati di interazione dovrebbero essere forniti dal server nella risposta.

3.Il server non dovrebbe archiviare alcuna informazione sul contesto della richiesta. Le richieste devono essere indipendenti e idempotenti (significa che se la stessa richiesta viene ripetuta all'infinito, viene recuperato esattamente lo stesso risultato)

E HTTP è solo un protocollo di comunicazione (uno strumento) che può aiutare a raggiungere questo obiettivo.

Per maggiori informazioni controlla questi link:

https://martinfowler.com/articles/richardsonMaturityModel.html http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

REST non è necessariamente legato a HTTP . I servizi Web RESTful sono solo servizi Web che seguono un'architettura RESTful.

What is Rest -
1- Client-server
2- Stateless
3- Cacheable
4- Layered system
5- Code on demand
6- Uniform interface

Da Non si conosce la differenza tra HTTP e REST

Quindi l'architettura REST e il protocollo HTTP 1.1 sono indipendenti l'uno dall'altro, ma il protocollo HTTP 1.1 è stato creato per essere il protocollo ideale per seguire i principi e i vincoli di REST. Un modo per esaminare la relazione tra HTTP e REST è che REST è la progettazione e HTTP 1.1 è un'implementazione di quella progettazione.

Le API REST devono essere guidate dall'ipertesto

Dal blog di Roy Fielding ecco una serie di modi per verificare se stai costruendo un'API HTTP o un'API REST:

Progettisti API, ti preghiamo di notare le seguenti regole prima di chiamare la tua creazione un'API REST:

• Un'API REST non dovrebbe dipendere da un singolo protocollo di comunicazione, sebbene la corretta mappatura a un determinato protocollo possa dipendere dalla disponibilità di metadati, dalla scelta dei metodi, ecc. In generale, qualsiasi elemento di protocollo che utilizza un URI per l'identificazione deve consentire qualsiasi schema URI da utilizzare a fini di tale identificazione. [Il fallimento qui implica che l'identificazione non è separata dall'interazione.]
• Un'API REST non deve contenere alcuna modifica ai protocolli di comunicazione oltre a compilare o correggere i dettagli di bit non specificati di protocolli standard, come il metodo PATCH HTTP o il campo di intestazione Link. Le soluzioni alternative per implementazioni non funzionanti (come quei browser abbastanza stupidi da credere che HTML definisca il set di metodi HTTP) dovrebbero essere definite separatamente, o almeno in appendici, con l'aspettativa che la soluzione alternativa alla fine sarà obsoleta. [Il fallimento qui implica che le interfacce delle risorse sono specifiche dell'oggetto, non generiche.]
• Un'API REST dovrebbe impiegare quasi tutto il suo sforzo descrittivo per definire i tipi di media utilizzati per rappresentare le risorse e guidare lo stato dell'applicazione, o per definire nomi di relazioni estese e / o mark-up abilitato per ipertesti per tipi di media standard esistenti. Qualsiasi sforzo speso per descrivere quali metodi utilizzare su quali URI di interesse dovrebbero essere interamente definiti nell'ambito delle regole di elaborazione per un tipo di supporto (e, nella maggior parte dei casi, già definito da tipi di supporto esistenti). [Il fallimento qui implica che le informazioni fuori banda guidano l'interazione anziché l'ipertesto.]
• Un'API REST non deve definire nomi o gerarchie di risorse fisse (un ovvio accoppiamento di client e server). I server devono avere la libertà di controllare il proprio spazio dei nomi. Consentire invece ai server di istruire i clienti su come costruire URI appropriati, ad esempio nei moduli HTML e nei modelli URI, definendo tali istruzioni all'interno dei tipi di media e delle relazioni di collegamento. [Il fallimento qui implica che i clienti stanno assumendo una struttura di risorse a causa di informazioni fuori banda, come uno standard specifico del dominio, che è l'equivalente orientato ai dati dell'accoppiamento funzionale di RPC].
• Un'API REST non dovrebbe mai disporre di risorse "tipizzate" significative per il client. Gli autori delle specifiche possono utilizzare i tipi di risorse per descrivere l'implementazione del server dietro l'interfaccia, ma tali tipi devono essere irrilevanti e invisibili per il client. Gli unici tipi significativi per un client sono il tipo di supporto della rappresentazione corrente e i nomi delle relazioni standardizzati. [idem]
• Un'API REST deve essere immessa senza alcuna conoscenza precedente oltre l'URI iniziale (segnalibro) e un set di tipi di media standardizzati appropriati per il pubblico previsto (vale a dire, che dovrebbe essere compreso 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 client delle scelte fornite dal server che sono presenti nelle rappresentazioni ricevute o implicite dalla manipolazione dell'utente di tali rappresentazioni. Le transizioni possono essere determinate (o limitate da) la conoscenza del cliente dei tipi di media e dei meccanismi di comunicazione delle risorse, entrambi i quali possono essere migliorati al volo (ad esempio, il codice su richiesta). [Il fallimento qui implica che le informazioni fuori banda stanno guidando l'interazione anziché l'ipertesto.]