Domanda Cos'è esattamente la programmazione RESTful?


Cos'è esattamente la programmazione RESTful?


3628
2018-03-22 14:45


origine


risposte:


Un stile architettonico chiamato REST (Representational State Transfer) sostiene che le applicazioni web dovrebbero usare HTTP così com'era originariamente previsto. Le ricerche dovrebbero usare GET richieste. PUT, POST, e DELETE richieste dovrebbe essere usato per mutazione, creazione e cancellazione rispettivamente.

I sostenitori di REST tendono a favorire gli URL, come ad esempio

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

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

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

è altrettanto riposante.

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

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

non sarebbe appropriato Le richieste GET dovrebbero essere idempotente. 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 "aggiungi al carrello" non è idempotente: emettendola due volte aggiunge due copie dell'articolo al carrello. Una richiesta POST è chiaramente appropriata in questo contesto. Quindi, anche a Applicazione web RESTful ha bisogno della sua parte di richieste POST.

Questo è tratto dal libro eccellente Core JavaServer faces libro di David M. Geary.


540
2018-04-15 11:26



RIPOSO è il principio architettonico di base del web. La cosa sorprendente del web è il fatto che i client (browser) e i server possono interagire in modi complessi senza che il client sappia nulla in anticipo sul server e le risorse che ospita. Il vincolo principale è che il server e il client devono entrambi essere d'accordo media usato, che nel caso del web è HTML.

Un'API che aderisce ai principi di RIPOSO non richiede che il client sappia qualcosa sulla struttura dell'API. Piuttosto, il server deve fornire tutte le informazioni necessarie al client per interagire con il servizio. Un Modulo HTML è un esempio di questo: il server specifica la posizione 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 è chiamato hateoas: Hypermedia As The Engine Of Application State.)

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

Ad esempio, immaginiamo di avere 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 + userdb e application / qualunque cosa + userdb - molti tipi di supporto possono essere supportati). Sia il client che il server sono stati programmati per comprendere questo formato, ma non sanno nulla l'uno dell'altro. Come Roy Fielding sottolinea:

Un'API REST dovrebbe impiegare quasi tutto il suo sforzo descrittivo in   definizione dei tipi di media utilizzati per rappresentare risorse e guida   stato dell'applicazione o nella definizione di nomi di relazioni estesi e / o   markup abilitato per ipertesto 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"
        }
    ]
}

Sappiamo dalla descrizione dei nostri media che possiamo trovare informazioni sulle risorse correlate da sezioni chiamate "link". Questo è chiamato Controlli ipermediali. In questo caso, possiamo dire da una tale sezione che possiamo trovare un elenco utenti facendo un'altra richiesta /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 tramite POST a /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, DELETE ecc.) Per manipolare queste risorse e che l'unica conoscenza che presumiamo sulla parte client è la nostra definizione media.

Ulteriori letture:

(Questa risposta è stata oggetto di una buona dose di critiche per aver mancato il punto: per la maggior parte è stata una bella critica. Quello che ho descritto in origine era più in linea con il modo in cui REST è stato implementato alcuni anni fa quando prima ho scritto questo, piuttosto che il suo vero significato. Ho rivisto la risposta per rappresentare meglio il vero significato.)


2788
2018-03-22 19:37



La programmazione RESTful riguarda:

  • risorse identificate da un identificatore persistente: gli URI sono la scelta ubiquitaria dell'identificatore in questi giorni
  • risorse manipolate usando un insieme comune di verbi: i metodi HTTP sono il caso comunemente visto - il venerabile Create, Retrieve, Update, Delete diventa 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: usa Accept header per controllare se vuoi XML, HTTP o anche un oggetto Java che rappresenta la risorsa
  • mantenere lo stato nell'oggetto e rappresentare lo stato nella rappresentazione
  • rappresentare le relazioni tra risorse nella rappresentazione della risorsa: i collegamenti tra gli oggetti sono incorporati direttamente nella rappresentazione
  • le rappresentazioni delle risorse descrivono come la rappresentazione può essere utilizzata e in quali circostanze dovrebbe essere scartata / rimessa in modo coerente: utilizzo delle intestazioni HTTP Cache-Control

L'ultimo è probabilmente il più importante in termini di conseguenze e di efficacia generale di REST. Nel complesso, la maggior parte delle discussioni RESTful sembrano centrare su HTTP e il suo utilizzo da un browser e cosa no. Capisco 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 di quanto non sia riguardo l'HTTP.

Se sei veramente interessato a cosa sia un'architettura RESTful e perché funzioni, leggi la sua tesi un paio di volte e leggere il l'intera cosa non solo il capitolo 5! Avanti guarda perché il DNS funziona. Leggi informazioni sull'organizzazione gerarchica del DNS e su 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 considerare come e perché la memorizzazione nella cache funziona come fa. Alla fine, farà semplicemente clic. La rivelazione finale per me è stata quando ho visto la somiglianza tra DNS e HTTP. Dopo questo, si inizia a fare clic sul motivo per cui le interfacce SOA e Message Passing sono scalabili.

Penso che sia il trucco più importante per comprendere l'importanza architettonica e le implicazioni di prestazioni di un RESTful e Niente condiviso le architetture è evitare di rimanere impigliati nei dettagli della tecnologia e dell'implementazione. Concentrati su chi possiede le risorse, chi è responsabile della loro creazione / manutenzione, ecc. Quindi pensa alle rappresentazioni, ai protocolli e alle tecnologie.


500
2017-07-04 05:47



Questo è quello che potrebbe sembrare.

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 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 (lname e age rimarrà invariato):

PATCH /user/123
fname=Johnny

Per aggiornare il record (e di conseguenza lname e age sarà NULL):

PUT /user/123
fname=Johnny

392
2017-11-18 20:46



Un grande libro su REST è REST in pratica.

Devono leggere sono Trasferimento dello stato di rappresentanza (REST) e Le API REST devono essere guidate da ipertesto 

Vedere l'articolo di Martin Fowlers Richardson Maturity Model (RMM) per una spiegazione su cosa sia un servizio RESTful.

Richardson Maturity Model

Per essere RESTful un servizio deve soddisfare il Hypermedia come il motore dello stato dell'applicazione. (Hateoas), cioè, deve raggiungere il livello 3 nell'RMM, leggi l'articolo per dettagli o il scivola dal discorso di qcon.

Il vincolo HATEOAS è un acronimo   per Hypermedia come il motore di   Stato dell'applicazione. Questo principio è   il principale elemento di differenziazione tra un REST   e la maggior parte delle altre forme di server client   sistema.

...

È necessario un client di un'applicazione RESTful   solo conoscere un singolo URL fisso per accedere   esso. Tutte le azioni future dovrebbero essere   scopribile dinamicamente da   collegamenti ipermediali inclusi nel   rappresentazioni delle risorse che   vengono restituiti da tale URL.   Sono anche i tipi di media standardizzati   dovrebbe essere compreso da nessuno   client che potrebbe utilizzare un'API RESTful.   (Da Wikipedia, l'enciclopedia libera)

REST Test al Litmus per Web Framework è un test di maturità simile per i framework web.

Avvicinarsi al puro REST: imparare ad amare HATEOAS è una buona raccolta di link.

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

REST e versioni discute Estensibilità, Versioning, Evolvability, ecc.  attraverso Modificabilità


170
2018-03-22 15:20



Cos'è REST?

REST sta per Representational State Transfer. (A volte è   compitato "ReST".) Si basa su un server stateless, client-server, memorizzabile nella cache   protocollo di comunicazione - e praticamente in tutti i casi, l'HTTP   il protocollo è usato

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

In molti modi, è possibile visualizzare lo stesso World Wide Web, basato su HTTP   come architettura basata su REST. Le applicazioni RESTful usano le richieste HTTP   per pubblicare dati (creare e / o aggiornare), leggere dati (ad esempio, creare query),   e cancellare i dati. Pertanto, REST utilizza HTTP per tutti e quattro i CRUD   (Crea / leggi / aggiorna / cancella) le operazioni.

REST è un'alternativa leggera a meccanismi come RPC (Remote   Procedure Chiamate) e servizi Web (SOAP, WSDL, ecc.). Più tardi, lo faremo   vedere quanto è più semplice il REST.

Nonostante sia semplice, REST è completo; c'è fondamentalmente   nulla che puoi fare nei servizi Web che non possono essere eseguiti con un RESTful   architettura. REST non è uno "standard". Non ci sarà mai un W3C   raccomandata per REST, per esempio. E mentre ci sono REST   i framework di programmazione, lavorare con REST è così semplice che puoi farlo   spesso "roll your own" con funzionalità di libreria standard in lingue come   Perl, Java o C #.

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

http://rest.elkstein.org/


128
2018-03-22 14:53



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

Anziché utilizzare un URL specifico per eliminare un metodo (ad esempio, /user/123/delete), si invierà una richiesta DELETE al /user/[id] URL, per modificare un utente, per recuperare informazioni su un utente a cui si invia una richiesta GET /user/[id]

Ad esempio, invece un insieme di URL che potrebbero apparire come alcuni 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

85
2017-07-12 16:33



È la programmazione in cui si adatta l'architettura del tuo sistema Stile di riposo presentato da Roy Fielding in la 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 architettura software come accademico o progettando servizi web, non c'è davvero alcuna ragione per aver sentito il termine.


63
2018-03-23 17:11



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

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

Learn REST: A Tutorial

REST è un stile architettonico per progettare applicazioni in rete.   L'idea è che, piuttosto che usare meccanismi complessi come CORBA,   RPC o SOAP per connettersi tra le macchine, viene utilizzato un semplice HTTP   chiamate tra le macchine.

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

Le applicazioni REST utilizzano le richieste HTTP per inviare dati (creare e / o   aggiornamento), leggere i dati (ad es. effettuare query) ed eliminare i dati. Quindi, REST   utilizza HTTP per tutte e quattro le operazioni CRUD (Crea / Leggi / Aggiorna / Elimina).

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


43
2017-07-25 09:05



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

C'è un buon esempio qui:

Spiegazione di REST e Hypertext: Spam-E il robot per la pulizia dello spam

E ancora meglio, c'è una spiegazione chiara con esempi semplici qui (il powerpoint è più completo, ma è possibile 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 potuto capire perché Ken sta dicendo che REST è guidato da un ipertesto. In realtà non sono sicuro che abbia ragione, perché / user / 123 è un URI che punta a una risorsa, e non mi è chiaro che è unRESTful solo perché il client lo sa "out-of-band".

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


43
2018-03-22 16:36