Puoi spiegare il concetto Web di RESTful?

Question

Alla ricerca di spiegazioni chiare e concise di questo concetto.

Answer 1

un'applicazione RESTful è un'applicazione che espone il suo stato e la funzionalità di un insieme di risorse che i clienti possono manipolare e conforme ad un certo insieme di principi:

• Tutte le risorse sono univocamente indirizzabile, di solito attraverso URI ; è possibile utilizzare anche altri indirizzamenti.
• Tutte le risorse possono essere manipolate tramite un insieme vincolato di azioni ben note, in genere CRUD (creazione, lettura, aggiornamento, eliminazione), rappresentate più spesso tramite POST, GET, PUT e DELETE dell'HTTP; tuttavia può essere un set diverso o un sottoinsieme - ad esempio, alcune implementazioni limitano quella impostata per leggere e modificare solo (GET e PUT) ad esempio
• I dati per tutte le risorse vengono trasferiti attraverso uno qualsiasi di un numero limitato di rappresentazioni note, in genere HTML, XML o JSON;
• La comunicazione tra il client e l'applicazione viene eseguita su un protocollo stateless che consente a più intermediari a più livelli di reindirizzare e memorizzare in cache le richieste e i pacchetti di risposta in modo trasparente per il client e l'applicazione.

Il Wikipedia article sottolineato da Tim Scott fornisce ulteriori dettagli circa l'origine del riposo, principi dettagliati, esempi e così via.

Answer 2

Significa utilizzare i nomi per identificare sia i comandi che i parametri.

Anziché i nomi sono semplici handle o moniker, il nome stesso contiene informazioni. Specificamente, informazioni su ciò che viene richiesto, parametri per la richiesta, ecc.

I nomi non sono "radici" ma piuttosto azioni più dati di input.

Answer 3

Francamente, la risposta dipende dal contesto. REST e RESTful hanno significati a seconda di quale lingua o struttura stai usando o cosa stai cercando di realizzare. Dato che hai taggato la tua domanda sotto "servizi web", risponderò nel contesto dei servizi web RESTful, che è ancora una categoria ampia.

I servizi Web RESTful possono significare qualsiasi cosa, da un'interpretazione REST rigorosa, in cui tutte le azioni vengono eseguite in modo rigoroso "RESTful", a un protocollo che è semplicemente XML, ovvero non SOAP o XMLRPC. In quest'ultimo caso, questo è un termine improprio: un tale protocollo REST è in realtà un "plain old XML" (or "POX") protocol. Mentre i protocolli REST di solito usano l'XML e come tali sono protocolli POX, questo non deve essere necessariamente il caso, e l'inverso non è vero (solo perché un protocollo usa XML non lo rende RESTful).

Senza ulteriori indugi, una vera API RESTful è costituita da azioni eseguite su oggetti, rappresentate dal metodo HTTP utilizzato e dall'URL di tale oggetto. Le azioni riguardano i dati e non riguardano il metodo. Ad esempio, le azioni CRUD (creazione, lettura, aggiornamento ed eliminazione) possono essere associate a un determinato insieme di URL e azioni. Diciamo che stai interagendo con un'API di foto.

• Per creare una foto, devi inviare i dati tramite una richiesta POST a/foto. Ti consente di sapere dove si trova la foto tramite l'intestazione Località, ad es./foto/12345
• Per visualizzare una foto, utilizzare GET/foto/12345
• Per aggiornare una foto, si inviano i dati tramite una richiesta PUT a/photos/12345.
• Per eliminare una foto, utilizzare DELETE/photos/12345
• Per ottenere un elenco di foto, utilizzare GET/foto.

Altre azioni potrebbero essere implementate, come la possibilità di copiare le foto tramite una richiesta di COPIA.

In questo modo, il metodo HTTP che si sta utilizzando mappa direttamente allo scopo della chiamata, invece di inviare l'azione che si desidera prendere come parte dell'API. Per contrastare, un'API non RESTful potrebbe utilizzare molti più URL e utilizzare solo le azioni GET e POST. Quindi, in questo esempio, si potrebbe vedere:

• Per creare una foto, inviare un POST a/foto/creare
• Per visualizzare una foto, inviare un GET per/foto/view/12345
• Per aggiornare una foto, invia un post a/foto/aggiornamento/12345
• Per eliminare una foto, invia un GET a/foto/cancella/12345
• Per ottenere un elenco di foto, invia un GET a/foto/lista

nota come in questo caso gli URL sono diversi e i metodi sono scelti solo per necessità tecniche: per inviare i dati, devi usare un POST, mentre tutte le altre richieste usano GET.

Answer 4

punti solo alcuni:

• ristoratore non dipende quadro si usa. Dipende dallo stile architettonico che descrive. Se non segui i vincoli, non sei RESTful. I vincoli sono definiti in mezza pagina del capitolo 5 del documento di Roy Fielding, ti incoraggio ad andare a leggerlo.
• L'identificatore è opaco e non ha cary alcuna informazione oltre l'identificazione di una risorsa. È un nmae, non dati di input, solo nomi. per quanto riguarda il client, non ha alcuna logica o valore oltre a sapere come costruire querystrings da un tag form. Se il tuo cliente costruisce i propri URI usando uno schema che hai deciso in anticipo, non sei riposante.
• L'uso o meno di tutti i verbi http non è realmente il vincolo ed è perfettamente accettabile progettare un'architettura che supporti solo POST.
• La memorizzazione nella cache, l'alto disaccoppiamento, la mancanza di stato della sessione e l'architettura a livelli sono i punti su cui si parla poco ma il più importante per il successo di un'architettura RESTful.

Se non trascorri la maggior parte del tuo tempo a creare il tuo formato di documento, probabilmente non stai facendo REST.

Answer 5

La spiegazione migliore che ho trovato è in questo .

Answer 6

Ho imparato di più dalla lettura degli articoli pubblicati su InfoQ.com: http://www.infoq.com/rest e dal libro dei servizi Web RESTful (http://oreilly.com/catalog/9780596529260/).

./alex

Diniego: Sono associato con InfoQ.com, ma questa raccomandazione è basata sulla mia esperienza di apprendimento.

Answer 7

REST a titolo di esempio:

POST /user 
fname=John&lname=Doe&age=25 

Il server risponde:

200 OK 
Location: /user/123 

In futuro, è possibile recuperare le informazioni dell'utente:

GET /user/123 

Il server risponde:

200 OK 
<fname>John</fname><lname>Doe</lname><age>25</age> 

aggiornare:

PUT /user/123 
fname=Johnny