Servizio web REST vs RESTful vs "normale"

21

Ho letto un paio di definizioni e discussioni su applicazioni REST e / o RESTful, ma non ne capisco ancora il vero significato.

Di solito lavoro con le app che recuperano i dati tramite GET o inviano i dati tramite POST ad alcuni servizi Web (di solito uno script PHP) che quindi ottengono i dati dal database o scrivono nel database.

Ora, questa è un'app RESTful? In caso contrario, quale sarebbe un'app RESTful? Qual è la differenza tra il concetto RESTful e il concetto con cui ho lavorato finora? Si prega di spiegare tramite un esempio.

Inoltre, qualcuno sta parlando del REST e qualcuno delle app RESTful. Ho scoperto che il termine REST si riferisce al concetto teorico, mentre RESTful viene utilizzato quando parliamo dell'app specifica. È giusto o ci sono differenze reali tra le app REST e RESTful?

— deviDave
fonte

1

Se riesci a creare tutti i tuoi servlet per estrarre SOLO le informazioni dai parametri GET o POST (assolutamente nulla salvato localmente prima della chiamata), stai applicando correttamente REST. In altre parole, il server svolge il ruolo del modello in MVC in quanto non ha il controllo ma utilizza semplicemente ciò che viene fornito per eseguire alcune attività. Spero che questo lo spieghi un po 'meglio.

— Neil,

@Neil Sono dall'altra parte - app mobile. È un client che utilizza il servizio Web e comunica con esso tramite POST e GET. Tutti i servizi web sono stati creati da qualcun altro e tutto quello che ho fatto è stato usarli. Ma la terminologia mi ha confuso. Quindi, se sto usando il canale HTTP e gli oggetti HttpGet / HttpPost, allora ho a che fare con un'app RESTful, giusto?

— deviDave,

Non necessariamente. Non c'è modo di sapere se si tratta di un'app RESTful se non si sa come viene eseguito il server poiché potrebbe violare alcuni vincoli. Detto questo, è probabilmente RESTful se restituisce risultati coerenti.

— Neil,

@Neil Oh, adesso capisco. RESTful viene eseguito sul server. E se invio un oggetto post con una richiesta (non ogni singolo parametro), probabilmente è un approccio REST. Per quanto riguarda un client (app mobile), non gli importa se è REST o meno, poiché la codifica è la stessa. Ho capito bene?

— deviDave,

2

RESTful è sia server che client, ma se puoi vedere solo il client, puoi solo sapere se il client segue i vincoli. Questo è tutto ciò che intendevo. Quello che intendo per REST è che, se devi effettuare il login, inserisci nome utente e password. Il server convalida l'accesso e salva la chiave hash dell'utente nel database e la restituisce. Ora, ogni volta che è necessario eseguire un'operazione che richiede l'accesso, si passa sempre la chiave hash dell'utente. Il server "dimentica" di aver effettuato l'accesso, ma utilizza l'hash dell'utente per convalidare lo stato di accesso. Se non fosse RESTful, il server ricorderebbe che hai effettuato l'accesso. Comprendi la differenza?

— Neil,

13

Gli attributi chiave di un'applicazione RESTful sono: Tutte le comunicazioni avvengono tramite http GET, POST, PUT, DELETE E tutti gli elementi vengono indirizzati tramite un URL standard del modulo, http://your.site.com/salesapp/salesperson/0000001/detailsovvero solo un URL puro senza parametri, ecc. L'URL identifica l'oggetto GET , POST, PUT, DELETE identifica ciò che si desidera fare.

La ragione principale per fare ciò è che si dispone automaticamente di un servizio senza stato che può essere bilanciato in base al carico, con failover ecc. Ecc.

La semplice semplicità dello schema crea un'interfaccia molto pulita, disaccoppiando totalmente il client da qualsiasi particolare implementazione back-end.

— James Anderson
fonte

Oh, finora non ho usato PUT o DELETE (le app mobili di solito fanno solo GET e POST), ma questo sembra davvero quello che ho fatto e che sto facendo al momento. È solo che i clienti non hanno usato i termini REST *, ma piuttosto "servizio web" e "script php"

— deviDave,

2

James, potresti spiegare perché i parametri della query devono essere evitati? Ad esempio, come posso esprimere che voglio che le risorse vengano filtrate in un modo particolare senza introdurre una falsa gerarchia?

— Gary Rowe,

3

@GaryRowe: l'URL (senza parametri) identifica la risorsa che si desidera manipolare. Puoi ancora avere parametri ma questi non vengono utilizzati per identificare la risorsa. Esempio: OTTENERE su una directory (un URL che termina con un /) dovrebbe restituire un elenco di risorse nella directory. Un parametro sull'URL può essere utilizzato per specificare un filtro o un tipo di ordinamento o qualcosa del genere.

— Martin York,

1

Grazie Loki. James potrebbe voler modificare la sua risposta per riflettere che, poiché sembra che non stia consentendo l'utilizzo dei parametri di query in circostanze che potrebbero essere fuorvianti. In realtà, c'è un'osservazione interessante che l'elenco delle risorse in una directory è di per sé una risorsa che esprime questo concetto.

— Gary Rowe,

REST non richiede che l'app sia basata su URL, né richiede di avere verbi come GET, POST, DELETE, ecc. Tuttavia, per una WebApp, l'URL è l'unica opzione e i suddetti verbi.

— Nawaz,

6

REST è l'acronimo di Representational State Transfer. Se il software è conforme ai Vincoli REST , viene considerato RESTful.

Bene, ora che ho strappato spudoratamente da Wikipedia, cosa significa veramente? Significa effettivamente utilizzare i comandi HTTP integrati come GET, POST, PUT, DELETE e alcuni altri più rari per comunicare avanti e indietro tra un client e un server.

Quello che stai facendo sembra essere un'app RESTFul. Tuttavia, c'è una grande differenza tra i servizi web RESTFul ben progettati e quelli in pila. Ad esempio, il codice PHP all'altra estremità del GET potrebbe eseguire il cambio di stato, il che sarebbe considerato errato poiché un GET è visto come un'operazione di sola lettura. Ci sono anche sottili differenze tra le modalità di utilizzo di POST (nuovo) e PUT (sostituzione).

L'articolo di Wikipedia su questo è in realtà davvero buono, quindi mi fermo qui.

— Martijn Verburg
fonte

Finora ho usato GET (HttpGet) per recuperare il contenuto e POST (HttpPost) per inserire / modificare il contenuto di un database. Ho inviato questo come parametro a HttpPost e lo script PHP sul server Web ha convertito questi parametri in codice SQL. È un'app RESTful? Sono interessato a un concetto, non a quanto bene sia stato fatto lo script PHP. Non ce l'ho fatta.

— deviDave,

2

Vorrei indagare sull'uso di PUT nel caso in cui si stia sostituendo il contenuto, il suo REST più idiomatico che utilizzare sempre POST.

— Martijn Verburg,

Sì, in tal caso utilizzerei PUT.

— deviDave,

+1 per notare che GET deve essere implementato correttamente (cioè è idempotente). Un errore così fondamentale nei primi tempi.

— Gary Rowe,

@deviDave Potresti anche voler esaminare PATCH, progettato per aggiornare parte di una risorsa. Come giustamente sottolinea Martin, PUT serve a sostituire l'intera risorsa.

— Gary Rowe,

4

Prima di andare oltre, questa domanda correlata può aiutarti

La differenza tra REST e RESTful è semplicemente la semantica. REST è uno stile architettonico applicato a una relazione client-server. RESTful è semplicemente un modo per dire ai tuoi clienti che usi REST.

Molte applicazioni web dichiarano di essere RESTful, ma in realtà sono solo parzialmente conformi ai vincoli REST (come anche Martijn Verburg ha fatto riferimento nella sua risposta). Li elencherò qui ma ti consiglio vivamente di leggere l'articolo:

Client-server
cacheable
Sistema a strati
Codice su richiesta (opzionale)

Dato che dici che lavori sul lato client, potrebbe essere utile vedere cosa ti darà e ti aspetterà un'architettura REST come client di connessione. Sebbene REST non sia HTTP, è di gran lunga il protocollo più popolare che supporta ciò che REST è quindi inquadrerò il mio esempio su questo.

Il tuo cliente dovrà:

utilizzare i verbi HTTP (ad es. GET, POST, PUT, DELETE, OPTIONS, PATCH) per eseguire le operazioni pertinenti
offerta Accetta le intestazioni e comprendi le intestazioni del tipo di contenuto (ad es. ricevi XML che non hai mai visto prima, ma puoi utilizzare un XSD di riferimento per creare un modello di dominio sul lato client da presentare al tuo utente)
segui i link offerti in un tipo di contenuto che comprendi (ad esempio induci il tuo utente o la tua applicazione a dedurre che <link rel="pay" href="http://example.org/orders(1)/payment">in HTML esprime una transizione di stato per creare una risorsa di pagamento tramite un POST con un corpo contenente alcuni XML che rappresenta i dettagli di pagamento come il numero di carta di credito , importo e così via)
reagire correttamente all'ampia gamma di codici di stato HTTP

Se fa quanto sopra, allora può essere pensato come un client REST, potresti voler chiamarlo "app RESTful" ma ciò implicherebbe piuttosto che stai usando REST sul lato client che è errato, quindi meglio evitare il termine.

— Gary Rowe
fonte

3

RESTful significa che l'interfaccia è un insieme di oggetti, che può essere letto e aggiornato (e possibilmente cancellato). Cioè non ci sono query multiparametriche (l'unico parametro è l'oggetto che si desidera leggere) e c'è solo un tipo di operazione che cambia qualsiasi cosa sul server, caricamento di nuovo stato.

Queste limitazioni assicurano che tutte le richieste siano idempotenti (l'invio più volte non ha alcun effetto aggiuntivo sul loro invio una volta). Questo è importante, perché la rete potrebbe non funzionare in qualsiasi momento e non fornire alcuna richiesta o risposta e con richieste idempotenti è sufficiente inviarlo di nuovo e non è necessario eseguire un ripristino complicato.

— Jan Hudec
fonte

Voto per il 1o paragrafo. Così conciso Grazie!

— deviDave,

Ancora una cosa, per vedere se ho capito bene. Se io (la mia app) sono un client del servizio REST, io come client non faccio caso se un servizio è RESTful oppure no poiché la mia codifica è sempre la stessa (httpget, httppost, ecc.)? Questo principio è importante solo per il proprietario di uno script / app del server?

— deviDave,

REST è una linea guida per la progettazione della semantica dell'interfaccia. La tecnologia di base è HTTP, indipendentemente dal fatto che l'interfaccia sia RESTful o meno (ma altri layer come XML-RPC o SOAP non sono rilevanti per le interfacce RESTful), quindi usi sempre lo stesso httpget, httppost ecc. Ma gestisci gli errori di rete in modo diverso.

— Jan Hudec,

per aggiungere, SMTP è un'interfaccia RESTful, sebbene utilizzi verbi diversi da GET, PUT ecc. e un protocollo sottostante diverso, il concetto è lo stesso: invii comandi basati su verbi idempotenti a un server.

— gbjbaanb,

Non tutte le richieste REST sono idempotenti. Ad esempio, l'emissione di un POST più volte comporterà molte nuove risorse.

— Gary Rowe,

Servizio web REST vs RESTful vs "normale" - uguale o no?