http - restful - servizi rest json




Qual è la differenza tra HTTP e REST? (10)

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

Ad esempio, potrei fare:

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

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

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

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 vostre risposte. Ora mi è diventato chiaro che REST è solo un insieme di regole su come usare HTTP. Quindi ho postato un follow-up su quali siano i vantaggi di queste convenzioni .

Nota : ora capisco il significato di REST; come osserva Emil Ivanov , REST significa usare HTTP come deve essere. Tuttavia, non sono sicuro se questo merita un termine a sé stante, e di certo non ne ricavo l'esagerazione.



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


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

REST significa che il concetto principale che si sta utilizzando mentre si progetta l'applicazione è la risorsa: per ogni azione che si desidera eseguire è necessario definire una risorsa su cui di solito si esegue solo l'operazione CRUD, che è un'operazione semplice. per questo è molto comodo 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 si ha una serie di azioni che si desidera eseguire come risultato della chiamata dell'utente. se pensi ad esempio a come descrivere un facebook come su un post, con RPC puoi creare servizi chiamati AddLikeToPost e RemoveLikeFromPost e gestirlo insieme a tutti gli altri tuoi servizi relativi ai post FB, quindi non avrai bisogno di creare speciali oggetto per come. con REST si avrà un oggetto Mi piace che sarà gestito separatamente con le funzioni Cancella e Crea. Significa anche che descriverà un'entità separata nel tuo db. potrebbe sembrare una piccola differenza, ma lavorare in questo modo produrrebbe di solito un codice molto più semplice e un'applicazione molto più semplice. con quel design, la maggior parte della logica dell'app è ovvia dalla struttura dell'oggetto (modello), a differenza di RPC con cui di solito dovresti aggiungere esplicitamente molta più logica.

progettare un'applicazione RESTful è solitamente molto più difficile perché richiede di descrivere le 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 scriveremo metodi molto più brevi.

Un'ulteriore restrizione dell'architettura REST presente non consiste nell'utilizzare il contesto di sessione durante la comunicazione con il client (stateless), ovvero tutte le informazioni necessarie per capire chi è il client e ciò che desidera viene passato con il messaggio Web. ogni chiamata a una funzione è auto-descrittiva, non vi è alcuna conversazione precedente con il client a cui si può fare riferimento nel messaggio. quindi un cliente non può dirti "dammi la prossima pagina" dato che non hai una sessione per memorizzare la pagina precedente e che tipo di pagina vuoi, il cliente dovrebbe dire "il mio nome è yuval, prendi pagina 2 di un post specifico in un forum specifico ". ciò significa che un po 'più di dati dovrebbero essere trasferiti nella comunicazione, ma si pensi alla differenza tra la ricerca di un bug segnalato dalla funzione "get me next page" in opposizione a "get me page 2 of question id 2190836 in ".

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


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

Oggi utilizziamo solo un piccolo bit dei metodi del protocollo HTTP, vale a dire GET e POST . Il modo REST per farlo è usare tutti i metodi del protocollo.

Ad esempio, REST detta l'uso di DELETE per cancellare un documento (sia esso un file, stato, ecc.) Dietro un URI, mentre, con HTTP, si farebbe un uso improprio di una query GET o POST come ...product/?delete_id=22 .


Non proprio...

REST

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

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

(Simple Object Access Protocol) Lo standard per i messaggi di servizi Web. Basato su XML, SOAP definisce un formato 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à non necessaria.


REST è un modo specifico di approccio alla progettazione di grandi sistemi (come il web).

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

HTTP è un protocollo che cerca di obbedire a quelle regole.


REST non aggiunge alcuna funzionalità specifica a HTTP ma è uno stile architettonico sviluppato insieme a HTTP e più comunemente utilizza HTTP per il suo protocollo a livello di applicazione.


Le API REST devono essere guidate da ipertesto

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

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

  • Un'API REST non dovrebbe dipendere da nessun singolo protocollo di comunicazione, sebbene la sua corretta mappatura a un determinato protocollo possa dipendere dalla disponibilità di metadati, scelta di metodi, ecc. In generale, qualsiasi elemento di protocollo che utilizza un URI per l'identificazione deve consentire qualsiasi schema URI da utilizzare per il bene 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 riempire o correggere i dettagli di bit di protocolli standard, come il metodo PATCH di HTTP o il campo dell'intestazione di collegamento. Soluzioni alternative per implementazioni errate (come quei browser abbastanza stupidi da credere che HTML definisca il set di metodi di HTTP) dovrebbero essere definite separatamente, o almeno in appendici, con l'aspettativa che la soluzione alternativa alla fine sarà obsoleta. [L'errore qui implica che le interfacce di risorse sono specifiche dell'oggetto, non generiche.]
  • Un'API REST deve dedicare quasi tutto il suo sforzo descrittivo alla definizione dei tipi di supporto utilizzati per rappresentare le risorse e guidare lo stato dell'applicazione, o nella definizione di nomi di relazione estesi e / o markup abilitato per ipertesti per i tipi di media standard esistenti. Qualsiasi sforzo impiegato 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 dai tipi di media esistenti). [Il fallimento qui implica che le informazioni fuori banda stanno guidando l'interazione invece dell'ipertesto.]
  • Un'API REST non deve definire nomi o gerarchie di risorse fisse (un accoppiamento ovvio tra client e server). I server devono avere la libertà di controllare il proprio spazio dei nomi. Invece, consentire ai server di istruire i clienti su come costruire URI appropriati, come avviene nei moduli HTML e nei modelli URI, definendo tali istruzioni all'interno dei tipi di media e delle relazioni di collegamento. [L'insuccesso qui implica che i clienti stiano 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 avere risorse "digitate" significative per il client. Gli autori delle specifiche possono utilizzare tipi di risorse per descrivere l'implementazione del server dietro l'interfaccia, ma questi tipi devono essere irrilevanti e invisibili per il client. Gli unici tipi significativi per un client sono il tipo di media della rappresentazione corrente e i nomi delle relazioni standardizzati. [idem]
  • 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.]

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






rest