Che cos'è esattamente la programmazione RESTful?

Che cos'è esattamente la programmazione RESTful?

Uno stile architettonico chiamato REST (Representational State Transfer) sostiene che le applicazioni web dovrebbero usare HTTP come era inizialmente previsto . Le ricerche dovrebbero usare le GETrichieste. PUT, POSTe le DELETErichieste devono essere utilizzate rispettivamente per la mutazione, la creazione e la cancellazione .

I sostenitori di REST tendono a privilegiare URL, come

http://myserver.com/catalog/item/1729

ma l'architettura REST non richiede questi "URL belli". Una richiesta GET con un parametro

http://myserver.com/catalog?item=1729

è altrettanto RESTful.

Tieni presente che le richieste GET non devono mai essere utilizzate per l'aggiornamento delle informazioni. Ad esempio, una richiesta GET per l'aggiunta di un articolo a un carrello

http://myserver.com/addToCart?cart=314159&item=1729

non sarebbe appropriato. Le richieste GET devono essere idempotenti . Cioè, l'emissione di una richiesta due volte non dovrebbe essere diversa dall'emissione di una volta. Questo è ciò che rende le richieste memorizzabili nella cache. Una richiesta di "aggiunta al carrello" non è idempotente: l'emissione due volte aggiunge due copie dell'articolo al carrello. Una richiesta POST è chiaramente appropriata in questo contesto. Pertanto, anche un'applicazione Web RESTful ha bisogno della sua quota di richieste POST.

Questo è tratto dall'eccellente libro Core JavaServer che affronta il libro di David M. Geary.

REST è il principio architettonico di base del web. La cosa sorprendente del Web è il fatto che client (browser) e server possono interagire in modi complessi senza che il client sappia in anticipo nulla sul server e sulle risorse che ospita. Il vincolo chiave è che il server e il client devono entrambi concordare sul supporto utilizzato, che nel caso del Web è HTML .

Un'API che aderisce ai principi di REST non richiede al client di conoscere nulla sulla struttura dell'API. Piuttosto, il server deve fornire tutte le informazioni necessarie al client per interagire con il servizio. Un modulo HTML ne è un esempio: il server specifica l'ubicazione della risorsa e i campi richiesti. Il browser non sa in anticipo dove inviare le informazioni e non sa in anticipo quali informazioni inviare. Entrambe le forme di informazione sono interamente fornite dal server. (Questo principio si chiama HATEOAS : Hypermedia come motore dello stato dell'applicazione .)

Quindi, come si applica a HTTP e come può essere implementato nella pratica? HTTP è orientato attorno a verbi e risorse. I due verbi nell'uso tradizionale sono GETe POST, che penso riconosceranno tutti. Tuttavia, lo standard HTTP ne definisce molti altri come PUTe DELETE. Questi verbi vengono quindi applicati alle risorse, secondo le istruzioni fornite dal server.

Ad esempio, immaginiamo di disporre di un database utente gestito da un servizio Web. Il nostro servizio utilizza un hypermedia personalizzato basato su JSON, per il quale assegniamo il mimetype application/json+userdb(potrebbe esserci anche un application/xml+userdbe application/whatever+userdb- molti tipi di media potrebbero essere supportati). Il client e il server sono stati entrambi programmati per comprendere questo formato, ma non si conoscono a vicenda. Come sottolinea Roy Fielding :

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.

Una richiesta per la risorsa di base /potrebbe restituire qualcosa del genere:

Richiesta

GET /
Accept: application/json+userdb

Risposta

200 OK
Content-Type: application/json+userdb

{
    "version": "1.0",
    "links": [
        {
            "href": "/user",
            "rel": "list",
            "method": "GET"
        },
        {
            "href": "/user",
            "rel": "create",
            "method": "POST"
        }
    ]
}

Dalla descrizione dei nostri media sappiamo che possiamo trovare informazioni sulle risorse correlate da sezioni chiamate "collegamenti". Questo si chiama controlli Hypermedia . In questo caso, da una tale sezione possiamo dire che possiamo trovare un elenco utenti facendo un'altra richiesta per /user:

Richiesta

GET /user
Accept: application/json+userdb

Risposta

200 OK
Content-Type: application/json+userdb

{
    "users": [
        {
            "id": 1,
            "name": "Emil",
            "country: "Sweden",
            "links": [
                {
                    "href": "/user/1",
                    "rel": "self",
                    "method": "GET"
                },
                {
                    "href": "/user/1",
                    "rel": "edit",
                    "method": "PUT"
                },
                {
                    "href": "/user/1",
                    "rel": "delete",
                    "method": "DELETE"
                }
            ]
        },
        {
            "id": 2,
            "name": "Adam",
            "country: "Scotland",
            "links": [
                {
                    "href": "/user/2",
                    "rel": "self",
                    "method": "GET"
                },
                {
                    "href": "/user/2",
                    "rel": "edit",
                    "method": "PUT"
                },
                {
                    "href": "/user/2",
                    "rel": "delete",
                    "method": "DELETE"
                }
            ]
        }
    ],
    "links": [
        {
            "href": "/user",
            "rel": "create",
            "method": "POST"
        }
    ]
}

Possiamo dire molto da questa risposta. Ad esempio, ora sappiamo che possiamo creare un nuovo utente POSTing /user:

Richiesta

POST /user
Accept: application/json+userdb
Content-Type: application/json+userdb

{
    "name": "Karl",
    "country": "Austria"
}

Risposta

201 Created
Content-Type: application/json+userdb

{
    "user": {
        "id": 3,
        "name": "Karl",
        "country": "Austria",
        "links": [
            {
                "href": "/user/3",
                "rel": "self",
                "method": "GET"
            },
            {
                "href": "/user/3",
                "rel": "edit",
                "method": "PUT"
            },
            {
                "href": "/user/3",
                "rel": "delete",
                "method": "DELETE"
            }
        ]
    },
    "links": {
       "href": "/user",
       "rel": "list",
       "method": "GET"
    }
}

Sappiamo anche che possiamo modificare i dati esistenti:

Richiesta

PUT /user/1
Accept: application/json+userdb
Content-Type: application/json+userdb

{
    "name": "Emil",
    "country": "Bhutan"
}

Risposta

200 OK
Content-Type: application/json+userdb

{
    "user": {
        "id": 1,
        "name": "Emil",
        "country": "Bhutan",
        "links": [
            {
                "href": "/user/1",
                "rel": "self",
                "method": "GET"
            },
            {
                "href": "/user/1",
                "rel": "edit",
                "method": "PUT"
            },
            {
                "href": "/user/1",
                "rel": "delete",
                "method": "DELETE"
            }
        ]
    },
    "links": {
       "href": "/user",
       "rel": "list",
       "method": "GET"
    }
}

Si noti che stiamo usando diversi verbi HTTP ( GET, PUT, POST, DELETEetc.) di manipolare queste risorse, e che l'unica conoscenza si presume da parte del cliente è la nostra definizione dei media.

Ulteriori letture:

• Le molte risposte molto migliori in questa stessa pagina.
• Come ho spiegato REST a mia moglie .
• Come ho spiegato REST a mia moglie .
• I pensieri di Martin Fowler
• L'API di PayPal ha controlli hypermedia

(Questa risposta è stata oggetto di una buona dose di critiche per aver mancato il punto. Per la maggior parte, questa è stata una giusta critica. Ciò che ho descritto in origine era più in linea con il modo in cui il REST era di solito implementato qualche anno fa quando per prima cosa ho scritto questo, piuttosto che il suo vero significato. Ho rivisto la risposta per rappresentare meglio il vero significato.)

La programmazione RESTful riguarda:

• risorse identificate da un identificatore persistente: gli URI sono la scelta onnipresente dell'identificatore in questi giorni
• risorse manipolati utilizzando un insieme comune di verbi: HTTP metodi sono il caso comunemente visto - il venerabile Create, Retrieve, Update, Deletediventa POST, GET, PUT, e DELETE. Ma REST non è limitato a HTTP, è solo il trasporto più comunemente usato in questo momento.
• la rappresentazione effettiva recuperata per una risorsa dipende dalla richiesta e non dall'identificatore: utilizzare le intestazioni Accept per controllare se si desidera XML, HTTP o persino un oggetto Java che rappresenta la risorsa
• mantenere lo stato nell'oggetto e rappresentare lo stato nella rappresentazione
• che rappresenta le relazioni tra risorse nella rappresentazione della risorsa: i collegamenti tra oggetti sono incorporati direttamente nella rappresentazione
• le rappresentazioni delle risorse descrivono come la rappresentazione può essere utilizzata e in quali circostanze deve essere scartata / recuperata in modo coerente: utilizzo delle intestazioni HTTP Cache-Control

L'ultimo è probabilmente il più importante in termini di conseguenze ed efficacia complessiva di REST. Nel complesso, la maggior parte delle discussioni su RESTful sembrano incentrate su HTTP e sul suo utilizzo da un browser e cosa no. Comprendo che R. Fielding ha coniato il termine quando ha descritto l'architettura e le decisioni che portano a HTTP. La sua tesi riguarda più l'architettura e la capacità di cache delle risorse che non l'HTTP.

Se sei davvero interessato a cos'è un'architettura RESTful e perché funziona, leggi la sua tesi alcune volte e leggi tutto non solo il capitolo 5! Ora guarda perché il DNS funziona . Leggi l'organizzazione gerarchica del DNS e come funzionano i referral. Quindi leggi e considera come funziona la memorizzazione nella cache DNS. Infine, leggi le specifiche HTTP ( RFC2616 e RFC3040 in particolare) e considera come e perché la memorizzazione nella cache funziona nel modo in cui funziona. Alla fine, farà semplicemente clic. La rivelazione finale per me è stata quando ho visto la somiglianza tra DNS e HTTP. Successivamente, capendo perché le interfacce SOA e Message Passing sono scalabili inizia a fare clic.

Penso che il trucco più importante per comprendere l'importanza architettonica e le implicazioni in termini di prestazioni delle architetture RESTful e Shared Nothing sia quello di evitare di rimanere impantanati sulla tecnologia e sui dettagli di implementazione. Concentrati su chi possiede risorse, chi è responsabile per la creazione / mantenimento di esse, ecc. Quindi pensa alle rappresentazioni, ai protocolli e alle tecnologie.

Ecco come potrebbe apparire.

Crea un utente con tre proprietà:

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

Il server risponde:

200 OK
Location: /user/123

In futuro, puoi quindi recuperare le informazioni dell'utente:

GET /user/123

Il server risponde:

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

Per modificare il record ( lnamee agerimarrà invariato):

PATCH /user/123
fname=Johnny

Per aggiornare il record (e di conseguenza lnamee agesarà NULL):

PUT /user/123
fname=Johnny

Un ottimo libro su REST è REST in Practice .

Le letture obbligatorie sono Representational State Transfer (REST) e le API REST devono essere guidate dall'ipertesto

Vedi l'articolo di Martin Fowlers sul modello di maturità Richardson (RMM) per una spiegazione di cosa sia un servizio RESTful.

Per essere RESTful, un servizio deve soddisfare Hypermedia come motore dello stato dell'applicazione. (HATEOAS) , ovvero deve raggiungere il livello 3 in RMM, leggere l'articolo per i dettagli o le diapositive dal discorso di qcon .

Il vincolo HATEOAS è l'acronimo di Hypermedia come Engine of Application State. Questo principio è il principale fattore di differenziazione tra un REST e la maggior parte delle altre forme di sistema server client.

...

Un client di un'applicazione RESTful deve solo conoscere un singolo URL fisso per accedervi. Tutte le azioni future dovrebbero essere individuabili in modo dinamico dai collegamenti ipertestuali inclusi nelle rappresentazioni delle risorse restituite da tale URL. I tipi di media standardizzati dovrebbero inoltre essere compresi da qualsiasi client che potrebbe utilizzare un'API RESTful. (Da Wikipedia, l'enciclopedia libera)

REST Tornasole Test per Web Frameworks è un test di maturità simile per i framework Web.

Avvicinarsi al puro RIPOSO: Imparare ad amare HATEOAS è una buona raccolta di collegamenti.

REST contro SOAP per il cloud pubblico discute gli attuali livelli di utilizzo REST.

REST e versioning discutono di estensibilità, versioning, evolvibilità, ecc. Attraverso la modificabilità

Che cos'è REST?

REST è l'acronimo di Representational State Transfer. (A volte è scritto "ReST".) Si basa su un protocollo di comunicazione memorizzabile nella cache senza client, server-server e, in quasi tutti i casi, viene utilizzato il protocollo HTTP.

REST è uno stile di architettura per la progettazione di applicazioni in rete. L'idea è che, anziché utilizzare meccanismi complessi come CORBA, RPC o SOAP per connettersi tra macchine, viene utilizzato HTTP semplice per effettuare chiamate tra macchine.

In molti modi, il World Wide Web stesso, basato su HTTP, può essere visto come un'architettura basata su REST. Le applicazioni RESTful utilizzano le richieste HTTP per pubblicare dati (creare e / o aggiornare), leggere dati (ad esempio, effettuare query) ed eliminare dati. Pertanto, REST utilizza HTTP per tutte e quattro le operazioni CRUD (Crea / Leggi / Aggiorna / Elimina).

REST è un'alternativa leggera a meccanismi come RPC (Remote Procedure Calls) e Web Services (SOAP, WSDL, et al.). Più avanti vedremo quanto è più semplice REST.

Nonostante sia semplice, REST è completo; non c'è praticamente nulla che tu possa fare nei servizi Web che non possa essere fatto con un'architettura RESTful. REST non è uno "standard". Non ci sarà mai una raccomandazione W3C per REST, per esempio. E mentre ci sono framework di programmazione REST, lavorare con REST è così semplice che spesso puoi "creare il tuo" con funzionalità di libreria standard in linguaggi come Perl, Java o C #.

Uno dei migliori riferimenti che ho trovato quando provo a trovare il semplice significato reale di riposo.

http://rest.elkstein.org/

REST utilizza i vari metodi HTTP (principalmente GET / PUT / DELETE) per manipolare i dati.

Invece di utilizzare un URL specifico per eliminare un metodo (diciamo, /user/123/delete), invieresti una richiesta DELETE /user/[id]all'URL, per modificare un utente, per recuperare informazioni su un utente a cui invii una richiesta GET/user/[id]

Ad esempio, invece un set di URL che potrebbe apparire come uno dei seguenti.

GET /delete_user.x?id=123
GET /user/delete
GET /new_user.x
GET /user/new
GET /user?id=1
GET /user/id/1

Usi i "verbi" HTTP e hai ..

GET /user/2
DELETE /user/2
PUT /user

È la programmazione in cui l'architettura del tuo sistema si adatta allo stile REST definito da Roy Fielding nella sua tesi . Poiché questo è lo stile architettonico che descrive il web (più o meno), molte persone sono interessate a questo.

Risposta bonus: No. A meno che tu non stia studiando l'architettura software come accademico o progettando servizi web, non c'è davvero motivo di aver sentito il termine.

Direi che la programmazione RESTful riguarderebbe la creazione di sistemi (API) che seguono lo stile architettonico REST.

Ho trovato questo fantastico tutorial breve e facile da capire su REST del Dr. M. Elkstein e citando la parte essenziale che avrebbe risposto alla tua domanda per la maggior parte:

Scopri REST: un tutorial

REST è uno stile di architettura per la progettazione di applicazioni in rete. L'idea è che, anziché utilizzare meccanismi complessi come CORBA, RPC o SOAP per connettersi tra macchine, viene utilizzato HTTP semplice per effettuare chiamate tra macchine.

• In molti modi, il World Wide Web stesso, basato su HTTP, può essere visto come un'architettura basata su REST.

Le applicazioni RESTful utilizzano le richieste HTTP per pubblicare dati (creare e / o aggiornare), leggere dati (ad esempio, effettuare query) ed eliminare dati. Pertanto, REST utilizza HTTP per tutte e quattro le operazioni CRUD (Crea / Leggi / Aggiorna / Elimina).

Non credo che dovresti sentirti stupido per non aver sentito parlare di REST fuori dallo Stack Overflow ..., sarei nella stessa situazione !; le risposte a questa altra domanda SO su Perché REST sta diventando grande ora potrebbe alleviare alcuni sentimenti.

Mi scuso se non rispondo direttamente alla domanda, ma è più facile capire tutto questo con esempi più dettagliati. La fielding non è facile da capire a causa di tutta l'astrazione e la terminologia.

C'è un buon esempio qui:

Spiegazione di REST e ipertesto: Spam-E Spam Cleaning Robot

E ancora meglio, c'è una spiegazione chiara con semplici esempi qui (il powerpoint è più completo, ma puoi ottenerne la maggior parte nella versione html):

http://www.xfront.com/REST.ppt o http://www.xfront.com/REST.html

Dopo aver letto gli esempi, ho capito perché Ken sta dicendo che REST è guidato dall'ipertesto. In realtà non sono sicuro che abbia ragione, perché / user / 123 è un URI che punta a una risorsa, e non è chiaro per me che è indolore solo perché il client lo conosce "fuori banda".

Quel documento xfront spiega la differenza tra REST e SOAP, e anche questo è davvero utile. Quando Fielding dice " Questo è RPC. Urla RPC. ", È chiaro che RPC non è RESTful, quindi è utile vedere i motivi esatti per questo. (SOAP è un tipo di RPC.)

Che cos'è REST?

REST in parole ufficiali, REST è uno stile architettonico basato su alcuni principi che utilizzano gli attuali principi del "Web". Esistono 5 fondamenti di base del Web sfruttati per creare servizi REST.

• Principio 1: tutto è una risorsa Nello stile architettonico REST, i dati e le funzionalità sono considerati risorse e sono accessibili tramite gli Uniform Resource Identifier (URI), in genere collegamenti sul Web.
• Principio 2: ogni risorsa è identificata da un identificatore univoco (URI)
• Principio 3: utilizzare interfacce semplici e uniformi
• Principio 4: la comunicazione è fatta per rappresentanza
• Principio 5: essere apolide

Vedo un mucchio di risposte che dicono che mettere tutto sull'utente 123 nella risorsa "/ user / 123" è RESTful.

Roy Fielding, che ha coniato il termine, afferma che le API REST devono essere guidate dall'ipertesto . In particolare, "Un'API REST non deve definire nomi o gerarchie di risorse fisse".

Quindi se il tuo percorso "/ user / 123" è hardcoded sul client, non è realmente RESTful. Un buon uso di HTTP, forse, forse no. Ma non RESTful. Deve venire dall'ipertesto.

La risposta è molto semplice, c'è una tesi scritta da Roy Fielding.] 1 In quella tesi definisce i principi REST. Se un'applicazione soddisfa tutti questi principi, questa è un'applicazione REST.

Il termine RESTful è stato creato perché ppl ha esaurito la parola REST chiamando la propria applicazione non REST come REST. Successivamente anche il termine RESTful fu esaurito. Oggi parliamo di API Web e API Hypermedia , perché la maggior parte delle cosiddette applicazioni REST non soddisfacevano la parte HATEOAS del vincolo uniforme dell'interfaccia.

I vincoli REST sono i seguenti:

1. architettura client-server

   Quindi non funziona con i socket PUB / SUB, ad esempio, si basa su REQ / REP.

2. comunicazione senza stato

   Quindi il server non mantiene gli stati dei client. Ciò significa che non è possibile utilizzare il server come archivio di sessioni secondarie e che è necessario autenticare ogni richiesta. I tuoi clienti potrebbero inviare le intestazioni di autenticazione di base tramite una connessione crittografata. (Per applicazioni di grandi dimensioni è difficile mantenere molte sessioni.)

3. utilizzo della cache, se possibile

   Quindi non è necessario soddisfare le stesse richieste ancora e ancora.

4. interfaccia uniforme come contratto comune tra client e server

   Il contratto tra il client e il server non è gestito dal server. In altre parole, il client deve essere disaccoppiato dall'implementazione del servizio. È possibile raggiungere questo stato utilizzando soluzioni standard, come lo standard IRI (URI) per identificare le risorse, lo standard HTTP per lo scambio di messaggi, i tipi MIME standard per descrivere il formato di serializzazione del corpo, i metadati (possibilmente vocab RDF, microformati, ecc.) Per descrivere la semantica delle diverse parti del corpo del messaggio. Per disaccoppiare la struttura IRI dal client, è necessario inviare collegamenti ipertestuali ai client in formati ipermediali come (HTML, JSON-LD, HAL, ecc.). Quindi un client può utilizzare i metadati (possibilmente relazioni di collegamento, vocab RDF) assegnati ai collegamenti ipertestuali per navigare nella macchina a stati dell'applicazione attraverso le transizioni di stato appropriate al fine di raggiungere il suo obiettivo attuale.

   Ad esempio, quando un cliente desidera inviare un ordine a un negozio online, deve controllare i collegamenti ipertestuali nelle risposte inviate dal negozio online. Controllando i collegamenti ne trova uno descritto con http://schema.org/OrderAction . Il client conosce il vocabolario di schema.org, quindi comprende che attivando questo collegamento ipertestuale invierà l'ordine. Quindi attiva il collegamento ipertestuale e invia un POST https://example.com/api/v1/ordermessaggio con il corpo appropriato. Successivamente il servizio elabora il messaggio e risponde con il risultato con l'intestazione di stato HTTP corretta, ad esempio 201 - createdper esito positivo. Per annotare i messaggi con metadati dettagliati, la soluzione standard per utilizzare un formato RDF, ad esempio JSON-LD con un vocabolario REST, ad esempio Hydra e vocab specifici del dominio comeschema.org o qualsiasi altro vocabolario di dati collegati e forse un vocabolario specifico dell'applicazione personalizzata, se necessario. Ora questo non è facile, ecco perché la maggior parte dei ppl usa HAL e altri formati semplici che di solito forniscono solo un vocabolario REST, ma nessun supporto per i dati collegati.

5. costruire un sistema a strati per aumentare la scalabilità

   Il sistema REST è composto da livelli gerarchici. Ogni livello contiene componenti che utilizzano i servizi di componenti che si trovano nel livello successivo di seguito. Quindi puoi aggiungere nuovi livelli e componenti senza sforzo.

   Ad esempio, esiste un livello client che contiene i client e di seguito un livello di servizio che contiene un singolo servizio. Ora puoi aggiungere una cache lato client tra di loro. Successivamente è possibile aggiungere un'altra istanza del servizio e un bilanciamento del carico e così via ... Il codice client e il codice servizio non cambieranno.

6. codice su richiesta per estendere le funzionalità del client

   Questo vincolo è facoltativo. Ad esempio, puoi inviare un parser per un tipo di supporto specifico al client, e così via ... Per fare ciò potresti aver bisogno di un sistema di caricamento caricatore di plugin standard nel client, o il tuo client sarà accoppiato alla soluzione di caricamento caricatore di plugin .

I vincoli REST risultano in un sistema altamente scalabile in cui i client sono disaccoppiati dalle implementazioni dei servizi. Quindi i client possono essere riutilizzabili, in generale proprio come i browser sul web. I clienti e i servizi condividono gli stessi standard e gli stessi vocaboli, quindi possono capirsi nonostante il fatto che il cliente non conosca i dettagli di implementazione del servizio. Ciò consente di creare client automatizzati in grado di trovare e utilizzare i servizi REST per raggiungere i propri obiettivi. A lungo termine questi clienti possono comunicare tra loro e fidarsi l'un l'altro dei compiti, proprio come fanno gli umani. Se aggiungiamo modelli di apprendimento a tali client, il risultato sarà una o più IA che utilizzano la rete di macchine anziché un parco server singolo. Quindi alla fine il sogno di Berners Lee: la rete semantica e l'intelligenza artificiale saranno realtà. Quindi nel 2030 finiamo per terminare con lo Skynet. Fino ad allora ... ;-)

La programmazione API RESTful (trasferimento dello stato rappresentativo) sta scrivendo applicazioni Web in qualsiasi linguaggio di programmazione seguendo 5 principi di base sullo stile dell'architettura software :

1. Risorsa (dati, informazioni).
2. Identificatore globale univoco (tutte le risorse sono univoche identificate dall'URI ).
3. Interfaccia uniforme : utilizzare l' interfaccia semplice e standard (HTTP).
4. Rappresentazione: tutte le comunicazioni vengono eseguite tramite rappresentazione (ad es. XML / JSON )
5. Stateless (ogni richiesta avviene in completo isolamento, è più facile memorizzare nella cache e bilanciare il carico),

In altre parole stai scrivendo semplici applicazioni di rete point-to-point su HTTP che usano verbi come GET, POST, PUT o DELETE implementando l'architettura RESTful che propone la standardizzazione dell'interfaccia che ogni “risorsa” espone. Non è nulla che utilizzare le attuali funzionalità del web in modo semplice ed efficace (architettura di successo, comprovata e distribuita). È un'alternativa a meccanismi più complessi come SOAP , CORBA e RPC .

La programmazione RESTful è conforme alla progettazione dell'architettura Web e, se correttamente implementata, consente di sfruttare appieno l'infrastruttura Web scalabile.

Se dovessi ridurre la tesi originale su REST a sole 3 frasi brevi, penso che quanto segue ne catturi l'essenza:

1. Le risorse sono richieste tramite URL.
2. I protocolli sono limitati a ciò che è possibile comunicare utilizzando gli URL.
3. I metadati vengono passati come coppie nome-valore (dati post e parametri della stringa di query).

Successivamente, è facile cadere nei dibattiti su adattamenti, convenzioni di codifica e migliori pratiche.

È interessante notare che non vi è alcuna menzione delle operazioni HTTP POST, GET, DELETE o PUT nella tesi. Questa deve essere la successiva interpretazione di una "best practice" per una "interfaccia uniforme".

Quando si tratta di servizi Web, sembra che abbiamo bisogno di un modo per distinguere le architetture basate su WSDL e SOAP che aggiungono notevole sovraccarico e probabilmente molta complessità superflua all'interfaccia. Richiedono inoltre ulteriori framework e strumenti di sviluppo per poter essere implementati. Non sono sicuro che REST sia il termine migliore per distinguere tra interfacce di buon senso e interfacce troppo ingegnerizzate come WSDL e SOAP. Ma abbiamo bisogno di qualcosa.

REST è un modello architettonico e uno stile di scrittura di applicazioni distribuite. Non è uno stile di programmazione in senso stretto.

Dire che usi lo stile REST è simile a dire che hai costruito una casa in uno stile particolare: ad esempio Tudor o Vittoriano. Sia REST come stile software sia Tudor o Victorian come stile domestico possono essere definiti dalle qualità e dai vincoli che li compongono. Ad esempio, REST deve avere una separazione Server Client in cui i messaggi si descrivono da soli. Le case in stile Tudor hanno timpani sovrapposti e tetti che sono fortemente inclinati con frontoni frontali. Puoi leggere la tesi di Roy per saperne di più sui vincoli e le qualità che compongono REST.

REST a differenza degli stili domestici ha avuto difficoltà a essere applicato in modo coerente e praticamente. Questo potrebbe essere stato intenzionale. Lasciando la sua effettiva attuazione fino al progettista. Quindi sei libero di fare quello che vuoi purché soddisfi i vincoli stabiliti nella tesi che stai creando REST Systems.

Bonus:

L'intero Web si basa su REST (o REST era basato sul Web). Pertanto, in qualità di sviluppatore web potresti volerlo sapere, sebbene non sia necessario scrivere buone app web.

Ecco il mio schema di base di REST. Ho cercato di dimostrare il pensiero dietro ciascuno dei componenti in un'architettura RESTful in modo che la comprensione del concetto sia più intuitiva. Spero che questo aiuti a demistificare il RESTO per alcune persone!

REST (Representational State Transfer) è un'architettura di progettazione che delinea il modo in cui le risorse di rete (ovvero i nodi che condividono informazioni) vengono progettate e indirizzate. In generale, un'architettura RESTful fa sì che il client (la macchina richiedente) e il server (la macchina rispondente) possano richiedere di leggere, scrivere e aggiornare i dati senza che il client debba sapere come funziona il server e il server può passare indietro senza bisogno di sapere nulla sul client. Okay, fico ... ma come facciamo in pratica?

• Il requisito più ovvio è che deve esistere un linguaggio universale di qualche tipo in modo che il server possa dire al client cosa sta cercando di fare con la richiesta e che il server risponda.

• Ma per trovare una determinata risorsa e poi dire al cliente dove vive quella risorsa, deve esserci un modo universale di indicare le risorse. È qui che entrano in gioco gli identificatori di risorse universali (URI); sono sostanzialmente indirizzi unici per trovare le risorse.

Ma l'architettura REST non finisce qui! Mentre quanto sopra soddisfa le esigenze di base di ciò che vogliamo, vogliamo anche avere un'architettura che supporti il ​​traffico ad alto volume poiché ogni dato server di solito gestisce le risposte da un numero di client. Pertanto, non vogliamo sopraffare il server facendogli ricordare le informazioni sulle richieste precedenti.

• Pertanto, imponiamo la limitazione che ogni coppia richiesta-risposta tra il client e il server è indipendente, il che significa che il server non deve ricordare nulla delle richieste precedenti (stati precedenti dell'interazione client-server) per rispondere a una nuova richiesta. Ciò significa che vogliamo che le nostre interazioni siano apolidi.

• Per alleviare ulteriormente la tensione sul nostro server dalla ripetizione dei calcoli che sono già stati eseguiti di recente per un determinato client, REST consente anche la memorizzazione nella cache. Fondamentalmente, la memorizzazione nella cache significa eseguire un'istantanea della risposta iniziale fornita al client. Se il client effettua nuovamente la stessa richiesta, il server può fornire al client l'istantanea anziché ripetere tutti i calcoli necessari per creare la risposta iniziale. Tuttavia, poiché si tratta di un'istantanea, se l'istantanea non è scaduta - il server imposta in anticipo un tempo di scadenza - e la risposta è stata aggiornata dalla cache iniziale (ovvero la richiesta darebbe una risposta diversa rispetto alla risposta memorizzata nella cache) , il client non vedrà gli aggiornamenti fino a quando la cache non scade (o la cache non viene cancellata) e la risposta viene nuovamente visualizzata da zero.

• L'ultima cosa che vedrai spesso qui sulle architetture RESTful è che sono stratificate. In realtà abbiamo già discusso implicitamente questo requisito nella nostra discussione sull'interazione tra client e server. Fondamentalmente, questo significa che ogni livello nel nostro sistema interagisce solo con livelli adiacenti. Pertanto, nella nostra discussione, il livello client interagisce con il nostro livello server (e viceversa), ma potrebbero esserci altri livelli server che aiutano il server primario a elaborare una richiesta con cui il client non comunica direttamente. Piuttosto, il server passa la richiesta secondo necessità.

Ora, se tutto ciò suona familiare, allora fantastico. L'Hypertext Transfer Protocol (HTTP), che definisce il protocollo di comunicazione tramite il World Wide Web è un'implementazione della nozione astratta di architettura RESTful (o un'istanza della classe REST se sei un fanatico di OOP come me). In questa implementazione di REST, il client e il server interagiscono tramite GET, POST, PUT, DELETE, ecc., Che fanno parte del linguaggio universale e le risorse possono essere indirizzate utilizzando gli URL.

Penso che il punto di riposo sia la separazione della statualità in un livello superiore mentre si fa uso di Internet (protocollo) come livello di trasporto senza stato . La maggior parte degli altri approcci mescola le cose.

È stato il miglior approccio pratico per gestire i cambiamenti fondamentali della programmazione nell'era di Internet. Per quanto riguarda i cambiamenti fondamentali, Erik Meijer ha una discussione in mostra qui: http://www.infoq.com/interviews/erik-meijer-programming-language-design-effects-purity#view_93197 . Lo riassume come i cinque effetti e presenta una soluzione progettando la soluzione in un linguaggio di programmazione. La soluzione potrebbe essere raggiunta anche a livello di piattaforma o di sistema, indipendentemente dalla lingua. Il riposo potrebbe essere visto come una delle soluzioni che ha avuto molto successo nella pratica attuale.

Con uno stile riposante, ottieni e manipoli lo stato dell'applicazione attraverso una rete inaffidabile. Se l'operazione corrente non riesce a ottenere lo stato corretto e corrente, è necessario che l'entità zero-validation aiuti l'applicazione a continuare. Se non riesce a manipolare lo stato, di solito utilizza più fasi di conferma per mantenere le cose corrette. In questo senso, il resto non è di per sé una soluzione completa, ma ha bisogno delle funzioni in altre parti dello stack dell'applicazione Web per supportarne il funzionamento.

Dato questo punto di vista, lo stile di riposo non è realmente legato a Internet o all'applicazione web. È una soluzione fondamentale per molte situazioni di programmazione. Non è nemmeno semplice, rende l'interfaccia davvero semplice e fa fronte ad altre tecnologie incredibilmente bene.

Solo il mio 2c.

Modifica: altri due aspetti importanti:

• L'apolidia è fuorviante. Riguarda l'API riposante, non l'applicazione o il sistema. Il sistema deve essere con stato. La progettazione riposante riguarda la progettazione di un sistema con stato basato su un'API senza stato. Alcune citazioni da un altro QA :

  • REST, opera su rappresentazioni di risorse, ognuna identificata da un URL. In genere non si tratta di oggetti dati, ma astrazioni di oggetti complessi .
  • REST sta per "trasferimento rappresentativo dello stato", il che significa che si tratta di comunicare e modificare lo stato di alcune risorse in un sistema.

• Idempotenza : una parte spesso trascurata di REST è l'idempotenza della maggior parte dei verbi. Ciò porta a sistemi robusti e meno interdipendenza delle interpretazioni esatte della semantica .

Questa è una "discussione" incredibilmente lunga eppure alquanto confusa per non dire altro.

IMO:

1) Non esiste una programmazione riposante, senza una grande articolazione e molta birra :)

2) Representational State Transfer (REST) ​​è uno stile architettonico specificato nella tesi di laurea di Roy Fielding . Ha una serie di vincoli. Se il tuo servizio / cliente li rispetta allora è RESTful. Questo è.

Puoi riassumere (in modo significativo) i vincoli a:

• comunicazione senza stato
• rispettare le specifiche HTTP (se si utilizza HTTP)
• comunica chiaramente i formati di contenuto trasmessi
• usa hypermedia come motore dello stato dell'applicazione

C'è un altro ottimo post che spiega bene le cose.

Molte risposte copiano / incollano informazioni valide mescolandole e aggiungendo un po 'di confusione. Qui le persone parlano dei livelli, degli URI RESTFul (non esiste una cosa del genere!), Applicano i metodi HTTP GET, POST, PUT ... REST non è solo questo o non solo.

Ad esempio i collegamenti: è bello avere un'API dall'aspetto accattivante, ma alla fine il client / server non si preoccupa davvero dei collegamenti che ottieni / invia, è il contenuto che conta.

Alla fine qualsiasi client RESTful dovrebbe essere in grado di consumare a qualsiasi servizio RESTful fintanto che il formato del contenuto è noto.

Vecchia domanda, nuovo modo di rispondere. Ci sono molti malintesi là fuori su questo concetto. Cerco sempre di ricordare:

1. URL strutturati e metodi / verbi Http non sono la definizione di programmazione riposante.
2. JSON non è una programmazione riposante
3. La programmazione RESTful non è per le API

Definisco programmazione riposante come

Un'applicazione è riposante se fornisce risorse (essendo la combinazione di dati + controlli delle transizioni di stato) in un tipo di supporto che il client comprende

Per essere un programmatore riposante devi cercare di creare applicazioni che consentano agli attori di fare le cose. Non solo esponendo il database.

I controlli di transizione dello stato hanno senso solo se il client e il server concordano su una rappresentazione del tipo di supporto della risorsa. Altrimenti non c'è modo di sapere cos'è un controllo e cosa non lo è e come eseguire un controllo. Ad esempio, se i browser non conoscessero i <form>tag in HTML, non ci sarebbe nulla da inviare allo stato di transizione nel browser.

Non sto cercando di autopromozione, ma espando queste idee a fondo nel mio discorso http://techblog.bodybuilding.com/2016/01/video-what-is-restful-200.html .

Un estratto dal mio discorso riguarda il modello di maturità richardson spesso riferito, non credo nei livelli, o sei RESTful (livello 3) o non lo sei, ma ciò che mi piace chiamarlo è ciò che ogni livello fa per te sulla strada per RESTful

REST definisce 6 vincoli architetturali che rendono qualsiasi servizio web - una vera API RESTful .

1. Interfaccia uniforme
2. Client-server
3. apolide
4. cacheable
5. Sistema a strati
6. Codice su richiesta (opzionale)

https://restfulapi.net/rest-architectural-constraints/

REST === L'analogia HTTP non è corretta finché non si sottolinea il fatto che "DEVE" essere guidato da HATEOAS .

Roy stesso l'ha cancellato qui .

Un'API REST deve essere immessa senza alcuna conoscenza al di là dell'URI iniziale (segnalibro) e di un set di tipi di media standardizzati appropriati per il pubblico previsto (ovvero, 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 guidano l'interazione anziché l'ipertesto.]

REST è uno stile architettonico basato sugli standard web e sul protocollo HTTP (introdotto nel 2000).

In un'architettura basata su REST, tutto è una risorsa (Utenti, Ordini, Commenti). Si accede a una risorsa tramite un'interfaccia comune basata sui metodi standard HTTP (GET, PUT, PATCH, DELETE ecc.).

In un'architettura basata su REST si dispone di un server REST che fornisce l'accesso alle risorse. Un client REST può accedere e modificare le risorse REST.

Ogni risorsa dovrebbe supportare le operazioni comuni HTTP. Le risorse sono identificate da ID globali (che in genere sono URI).

REST consente che le risorse abbiano rappresentazioni diverse, ad es. Testo, XML, JSON ecc. Il client REST può richiedere una rappresentazione specifica tramite il protocollo HTTP (negoziazione del contenuto).

Metodi HTTP:

I metodi PUT, GET, POST e DELETE sono tipici utilizzati nelle architetture basate su REST. La tabella seguente fornisce una spiegazione di queste operazioni.

• GET definisce un accesso in lettura alla risorsa senza effetti collaterali. La risorsa non viene mai modificata tramite una richiesta GET, ad es. La richiesta non ha effetti collaterali (idempotente).
• PUT crea una nuova risorsa. Deve anche essere idempotente.
• DELETE rimuove le risorse. Le operazioni sono idempotenti. Possono essere ripetuti senza portare a risultati diversi.
• POST aggiorna una risorsa esistente o crea una nuova risorsa.

REST è l' acronimo di Rappresentational state transfer .

Si basa su un protocollo di comunicazione memorizzabile nella cache senza client, server-server e, in quasi tutti i casi, viene utilizzato il protocollo HTTP.

REST viene spesso utilizzato in applicazioni mobili, siti Web di social network, strumenti di mashup e processi aziendali automatizzati. Lo stile REST sottolinea che le interazioni tra clienti e servizi sono migliorate con un numero limitato di operazioni (verbi). La flessibilità è fornita assegnando alle risorse (nomi) i propri indicatori di risorse universali (URI) unici.

Introduzione sul riposo

Parlare è più che semplicemente scambiare informazioni . Un protocollo è in realtà progettato in modo tale che non si debba parlare. Ciascuna parte sa qual è il proprio lavoro particolare perché è specificato nel protocollo. I protocolli consentono un puro scambio di informazioni a scapito di eventuali cambiamenti nelle possibili azioni. Parlare, d'altra parte, consente a una parte di chiedere quali ulteriori azioni possono essere intraprese dall'altra parte. Possono anche porre la stessa domanda due volte e ottenere due risposte diverse, poiché lo Stato dell'altra parte potrebbe essere cambiato nel frattempo. Parlare è un'architettura RESTful . La tesi di Fielding specifica l'architettura che si dovrebbe seguire se si volesse consentire alle macchine di parlare tra loro piuttosto che semplicementecomunicare .

Di per sé non esiste una nozione come "programmazione RESTful". Sarebbe meglio chiamato paradigma RESTful o ancora migliore architettura RESTful. Non è un linguaggio di programmazione. È un paradigma.

Da Wikipedia :

Nell'informatica, il trasferimento di stato rappresentazionale (REST) ​​è uno stile architettonico utilizzato per lo sviluppo web.

Il punto di riposo è che se accettiamo di usare un linguaggio comune per le operazioni di base (i verbi http), l'infrastruttura può essere configurata per comprenderli e ottimizzarli correttamente, ad esempio, facendo uso delle intestazioni della cache per implementare affatto la cache livelli.

Con un'operazione GET riposante correttamente implementata, non dovrebbe importare se le informazioni provengono dal DB del server, dalla memcache del server, da una CDN, dalla cache di un proxy, dalla cache del browser o dalla memoria locale del browser. È possibile utilizzare l'origine aggiornata a digiuno, più prontamente disponibile.

Dire che Rest è solo una modifica sintattica dall'uso delle richieste GET con un parametro di azione all'utilizzo dei verbi http disponibili fa sembrare che non abbia vantaggi ed è puramente cosmetico. Il punto è usare un linguaggio che può essere compreso e ottimizzato da ogni parte della catena. Se la tua operazione GET ha un'azione con effetti collaterali, devi saltare tutta la memorizzazione nella cache HTTP o otterrai risultati incoerenti.

Che cos'è il test API ?

Il test API utilizza la programmazione per inviare chiamate all'API e ottenere il rendimento. Il test considera il segmento in prova come una scatola nera. L'obiettivo del test API è confermare la corretta esecuzione e il trattamento errato della parte che precede il suo coordinamento in un'applicazione.

API REST

RIPOSTO: trasferimento rappresentativo dello stato.

• È una disposizione di funzioni su cui i tester eseguono richieste e ricevono risposte. In REST API le interazioni vengono effettuate tramite protocollo HTTP.
• REST consente inoltre la comunicazione tra computer in rete.
• Per l'invio e la ricezione di messaggi, implica l'utilizzo di metodi HTTP e non richiede una definizione rigorosa dei messaggi, a differenza dei servizi Web.
• I messaggi REST spesso accettano il modulo in formato XML o JavaScript Object Notation (JSON).

4 metodi API comunemente usati: -

1. OTTIENI: - Fornisce l'accesso in sola lettura a una risorsa.
2. POST: - Viene utilizzato per creare o aggiornare una nuova risorsa.
3. PUT: - Viene utilizzato per aggiornare o sostituire una risorsa esistente o creare una nuova risorsa.
4. ELIMINA: - Viene utilizzato per rimuovere una risorsa.

Passaggi per testare manualmente l'API: -

Per utilizzare manualmente l'API, possiamo utilizzare i plug-in API REST basati su browser.

1. Installa il plugin POSTMAN (Chrome) / REST (Firefox)
2. Inserisci l'URL dell'API
3. Seleziona il metodo REST
4. Seleziona intestazione contenuto
5. Inserisci richiesta JSON (POST)
6. Clicca su Invia
7. Restituirà una risposta in uscita

I passaggi per automatizzare l'API REST

Questo è molto meno menzionato ovunque, ma il modello di maturità di Richardson è uno dei metodi migliori per giudicare effettivamente quanto API API sia riposante. Maggiori informazioni qui:

Modello di maturità di Richardson

Direi che un importante elemento di base nella comprensione del REST risiede negli endpoint o nelle mappature, come ad esempio /customers/{id}/balance.

È possibile immaginare un endpoint come la pipeline di connessione dal sito Web (front-end) al database / server (back-end). Usandoli, il front-end può eseguire operazioni di back-end definite nei metodi corrispondenti di qualsiasi mapping REST nella propria applicazione.