32 Domanda: Cos'è esattamente la programmazione RESTful?

domanda creata a Thu, Mar 16, 2017 12:00 AM

Che cos'è esattamente la programmazione RESTful?

    
3856
  1. vedi anche la risposta al seguente link stackoverflow.com/a/37683965 /3762855
    2016-06-07 19: 59: 49Z
  2. REST potrebbe diventare un po 'vecchio ora;) youtu.be /WQLzZf34FJ8
    2016-07-16 01: 50: 38Z
  3. Inoltre, fai riferimento a questo link per ulteriori informazioni news.ycombinator.com/item?id=3538585
    2017-02-18 12: 38: 56Z
  4. 2017-08-25 07: 11: 57Z
  5. @ OLIVER.KOO bella osservazione. È solo che l'ho chiesto in un momento in cui era una specie di novità. Era stato gettato molto, ma non molte persone sapevano di cosa si trattava. Almeno non l'ho fatto, e sembra che chiedermi questo li abbia aiutati perché anche loro volevano sapere.
    2018-02-26 03: 18: 30Z
30 risposte                              30                         

Uno stile architettonico chiamato REST (Representational State Transfer) sostiene che le applicazioni web dovrebbero utilizzare HTTP com'era inizialmente previsto . Le ricerche devono utilizzare le richieste GET . Le richieste PUT, POST e DELETE devono essere utilizzate per la mutazione, creazione e cancellazione rispettivamente .

I sostenitori di REST tendono a favorire gli URL, come

 
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 RESTful.

Tieni presente che le richieste GET non dovrebbero 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 "aggiungi al carrello" non è idempotente: emettendola due volte aggiunge due copie dell'articolo al carrello. Una richiesta POST è chiaramente appropriata in questo contesto. Pertanto, anche un'applicazione RESTful richiede la sua condivisione di richieste POST.

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

    
669
2018-03-27 09: 14: 52Z
  1. Lisiting Available Idempotent Operations: GET (Safe), PUT & DELETE (l'eccezione è menzionata in questolink restapitutorial.com/lessons/idempotency.html). Riferimento aggiuntivo per Safe & Metodi idempotenti w3.org/Protocols/rfc2616/rfc2616-sec9.html
    2015-07-21 04: 00: 20Z
  2. a) il punto importante su GET è la sicurezza, non l'idempotenza, b) @Abhijeet: RFC 2616 è stato obsoleto nel 2014; vedi RF 7230ff.
    2016-05-06 06: 16: 03Z
  3. Questo è sbagliato. Leggi questo per la corretta interpretazione di REST roy.gbiv.com /untangled /2008 /rest-apis-must-be-hypertext-driven o questo stackoverflow.com/questions/19843480/...
    2017-08-25 07: 09: 35Z
  4. @ kushalvm Questa definizione accademica di REST non viene utilizzata nella pratica.
    2017-08-27 15: 31: 14Z
  5. In effetti possiamo chiederci se un concetto è operativo poiché non riusciamo a dargli una definizione stabile e comprensibile per tutti
    2018-05-03 23: 03: 30Z

REST è il principio architettonico sottostante 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 chiave è che il server e il client devono entrambi essere d'accordo sul supporto usato, che nel caso del web è HTML .

Un'API che rispetti i principi di REST non richiede al cliente di conoscere nulla sulla struttura dell'API. Piuttosto, il server deve fornire tutte le informazioni che il cliente ha bisogno 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 informazioni sono fornite dal server. (Questo principio è chiamato HATEOAS : Hypermedia As The Engine Of Application State .)

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 GET e POST, che credo 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 (potrebbero esserci anche un application/xml+userdb e un application/whatever+userdb - potrebbero essere supportati molti tipi di media). 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 hypertext per tipi di media standard esistenti.

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

Richiesta ​​strong>

 
GET /
Accept: application/json+userdb

risposta ​​strong>

 
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 Hypermedia . In questo caso, possiamo dire da una tale sezione che possiamo trovare un elenco utenti facendo un'altra richiesta per /user:

Richiesta ​​strong>

 
GET /user
Accept: application/json+userdb

risposta ​​strong>

 
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"
        }
    ]
}

Possiamoraccontare molto da questa risposta. Ad esempio, ora sappiamo che possiamo creare un nuovo utente da POST a /user:

Richiesta ​​strong>

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

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

risposta ​​strong>

 
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 ​​strong>

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

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

risposta ​​strong>

 
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 utilizzando diversi verbi HTTP (GET, PUT, POST, DELETE, ecc.) per manipolare queste risorse e che l'unica conoscenza che presumiamo sulla parte del cliente è 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 di solito da alcuni anni fa quando scrissi per la prima volta questo, piuttosto che il suo vero significato. Ho rivisto la risposta per rappresentare meglio il vero significato.)

    
2877
2019-04-10 15: 31: 47Z
  1. No. REST non è comparso solo come un'altra parola chiave. È nato come mezzo per descrivere un'alternativa allo scambio di dati basato su SOAP. Il termine REST aiuta a inquadrare la discussione su come trasferire e accedere ai dati.
    2009-03-22 15: 11: 52Z
  2. Tuttavia, il cuore di REST (nell'applicazione pratica) è "non utilizzare GET per apportare modifiche, usa POST /PUT /DELETE", che è un consiglio I ' Ho sentito (e seguito) da molto prima che apparisse SOAP. REST ha sempre presente, ma non ha ottenuto un nome oltre "il modo di farlo" fino a poco tempo fa.
    2009-03-22 15: 16: 54Z
  3. Non dimenticare "Hypertext come motore dello stato dell'applicazione".
    2009-03-22 15: 54: 39Z
  4. Questa risposta manca il punto. HTTP è appena citato nella tesi di Fielding.
    2010-11-18 02: 22: 49Z
  5. Questa risposta non menziona lo scopo di REST e fa sembrare che si tratti di URI puliti. Mentre questa potrebbe essere la percezione popolare di REST, le risposte di D.Shawley e oluies sono più accurate - si tratta di essere in grado di sfruttare le funzionalità integrate nell'architettura, come il caching, lavorando con esso anziché contro di esso. Gli URI più carini sono per lo più un effetto collaterale comune.
    2010-12-20 20: 49: 03Z

La programmazione RESTful riguarda:

  • risorse identificate da un identificatore persistente: gli URI sono la scelta ubiquitaria dell'identificatore in questi giorni
  • risorse manipolate utilizzando un insieme comune di verbi: i metodi HTTP sono il caso comune - 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
  • mantenimento dello stato nell'oggetto e rappresentazione dello stato nella rappresentazione
  • rappresenta le relazioni tra le 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 sotto qualicircostanze dovrebbe essere scartato /rimesso 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 rispetto a quanto riguarda l'HTTP.

Se sei veramente interessato a cosa sia un'architettura RESTful e perché funzioni, leggi la sua tesi un paio di volte e leggi la intera cosa non solo il Capitolo 5! Esamina il 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 considera 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, capire perché le interfacce SOA e Message Passing sono scalabili inizia a fare clic.

Penso che sia il trucco più importante per capire l'importanza architettonica e le implicazioni di rendimento di RESTful e Shared Nothing architetture è quello di evitare di rimanere impigliato 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.

    
524
2016-11-02 21: 23: 58Z
  1. Una risposta che fornisce una lista di lettura è molto appropriata per questa domanda.
    2012-02-01 19: 50: 55Z
  2. Grazie per l'aggiornamento. PUT e POST non sono realmente mappati one-to-one con aggiornamento e creazione. PUT può essere usato per creare se il cliente sta dettando quale sarà l'URI. POST crea se il server sta assegnando il nuovo URI.
    2012-02-01 23: 30: 14Z
  3. Non dimenticare PATCH.
    2013-09-16 15: 20: 27Z
  4. Un URN è un URI che utilizza lo schema urn:. Concettualmente non c'è differenza; tuttavia, un URN richiede che si disponga di un metodo definito separatamente per "localizzare" la risorsa identificata (nominata) dall'URN. Bisogna fare attenzione per assicurarsi di non introdurre un accoppiamento implicito quando si mettono in relazione risorse nominate e la loro posizione.
    2014-03-30 14: 45: 37Z
  5. @ ellisbben Concordato. Se capisco correttamente questa è la tesi che ha dato origine a REST: ics .uci.edu /~ fielding /pub /tesi di laurea /rest_arch_style.htm
    2014-09-10 12: 56: 12Z

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 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 rimarranno invariati):

 
PATCH /user/123
fname=Johnny

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

 
PUT /user/123
fname=Johnny
    
404
2017-02-06 20: 23: 38Z
  1. Per me questa risposta ha catturato l'essenza della risposta desiderata: semplice e pragmatica: ammesso che ci siano molti altri criteri, ma l'esempio fornito è un ottimo trampolino di lancio.
    2012-02-01 22: 09: 41Z
  2. Nell'ultimo esempio, @pbreitenbach usa PUT fname=Jonny. Ciò imposterà lname e age su valori predefiniti (probabilmente NULL o stringa vuota e intero 0), perché un PUT sovrascrive l'intera risorsa con i dati della rappresentazione fornita. Questo non è ciò che è implicito da "aggiornamento", per fare un aggiornamento reale, utilizzare il metodo PATCH in quanto ciò non modifica i campi che non sono specificati nella rappresentazione.
    2013-01-31 09: 43: 18Z
  3. Nicholas ha ragione. Inoltre, l'URI per il primo POST che crea un utente dovrebbe essere chiamato utente perché /user/1 non ha senso e dovrebbe esserci un elenco a /users. La risposta dovrebbe essere 201 Created e non solo OK in quel caso.
    2013-02-16 19: 58: 38Z
  4. Questo è solo un esempio di API non necessariamente api RESTful. Un RESTful ha vincoli a cui aderisce. Architettura client-server, Stateless, Cache-ability, Layered System, Uniform Interface.
    2018-06-26 22: 11: 08Z
  5. Questa è una risposta molto compatta che copre tutti i metodi di accesso al servlet http
    2019-01-03 19: 45: 21Z

Un ottimo libro su REST è REST in pratica .

Le letture obbligatorie sono Representational State Transfer (REST) ​​ e Le API REST devono essere basate su ipertesti

Vedi l'articolo di Martin Fowlers Modello di maturità Richardson (RMM) per una spiegazione su ciò che un RESTful il servizio è

Modello di maturità di Richardson

Per essere RESTful, un Servizio deve soddisfare il 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 del qcon talk .

  

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 capito da nessuno   client che potrebbe utilizzare un'API RESTful.   (Da Wikipedia, l'enciclopedia libera)

REST Test al Litmus per i Web Framework è una scadenza simile test per i framework web.

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

REST contro SOAP per il Public Cloud illustra gli attuali livelli di utilizzo di REST.

REST e versioning discutono di estensibilità, gestione delle versioni, evolvibilità, eccetera.  tramite Modificabilità

    
178
2013-09-08 17: 43: 09Z
  1. Penso che questa risposta tocchi il punto chiave della comprensione di REST: cosa significa la parola representational . Livello 1 - Le risorse dicono di stato . Livello 2 - Verbi HTTP dice di trasferimento (leggi cambia ). Livello 3 - HATEOAS afferma di guidare i futuri trasferimenti tramite la rappresentazione (JSON /XML /HTML restituito), il che significa che hai saputo come dire il prossimo round di discussione con le informazioni restituite. Quindi REST legge: "(representational (state transfer))", invece di "((stato di rappresentazione) trasferimento".
    2014-12-09 19: 49: 34Z
  2. 2018-02-08 22: 41: 37Z
  

Che 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 un'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 /Elimina).

     

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

     

Nonostante sia semplice, REST è completamente equipaggiato; c'è fondamentalmente   niente 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 provo a trovare il semplice significato reale di riposo.

http://rest.elkstein.org/

    
133
2013-10-28 23: 07: 52Z
  1. Questa è una risposta davvero concisa. Puoi anche descrivere perché il REST è chiamato stateless?
    2019-02-12 17: 15: 49Z

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

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

Ad esempio, invece una serie di URL che potrebbero apparire come i 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
    
88
2009-03-22 15: 20: 09Z
  1. Questo è "using HTTP correttamente", che non è lo stesso di "restful" (sebbene sia collegato ad esso)
    2009-03-22 15: 56: 25Z
  2. Puoi anche usare /user /del /2 e /user /remove /2 o ... GET /DELETE /PUT /POST sono solo standardizzati, "corretto" "modo di fare queste cose (e come dice Julian, quellonon è tutto quello che c'è da REST) ​​
    2009-06-02 21: 32: 20Z
  3. Certo, ma non c'è ragione di evitarli .. REST ti fa risparmiare ogni volta di reinventare la ruota. Per un'API, REST è fantastico (consistenza!), Ma per strutturare un sito web a caso non ha molta importanza, direi (può essere più complicato di quello che vale)
    2009-06-03 22: 34: 09Z
  4. Vadim, sarebbe semplicemente RPC. È anche pericoloso utilizzare GET per modificare i dati poiché (tra gli altri motivi) un motore di ricerca può spiderare i collegamenti di eliminazione e visitarli tutti.
    2009-07-20 17: 35: 20Z
  5. @ aehlke - Penso che la vera domanda sarebbe "Perché un utente anonimo ha la possibilità di cancellare record dal tuo sistema?"
    2014-12-03 05: 28: 19Z

È la programmazione in cui l'architettura del tuo sistema si adatta allo stile REST presentato da Roy Fielding in 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 alcun motivo per aver sentito il termine.

    
67
2009-03-22 15: 56: 19Z
  1. ma non straight-forward .. rende più complicato che sia necessario.
    2009-03-22 15: 38: 08Z
  2. Inoltre, anche se i termini REST e RESTful sono usati quasi esclusivamente nel regno delle applicazioni web in questo momento, tecnicamente non c'è niente che leghi REST a HTTP.
    2009-03-22 15: 52: 50Z
  3. Il blog di Fielding ha degli articoli buoni e più comprensibili su REST e idee sbagliate comuni: roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
    2009-07-20 17: 32: 53Z
  4. @ HankGay Penso che la ragione per cui non è più esoterico è che la maggior parte degli sviluppatori di servizi Web vede REST come una meravigliosa semplificazione rispetto alle alternative come SOAP. Non si attengono necessariamente a ottenere tutti i tecnicismi di REST corretti - e questo probabilmente fa impazzire i fanatici di REST - ma nella maggior parte dei casi probabilmente non devono preoccuparsi di cose come assicurarsi che i loro risultati siano "abilitati all'ipermedia".
    2013-07-04 11: 56: 12Z

    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.

    Qui c'è un buon esempio:

    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 puoi ottenere la maggior parte di esso 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 è basato su ipertesto. Non sono sicuro che lui siaè giusto, perché quel /user /123 è un URI che punta a una risorsa, e non mi è chiaro che è unRESTful solo perché il client lo sa "fuori banda".

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

        
    45
    2017-09-06 20: 26: 46Z
    1. link interessanti, grazie. Sono stanco di questi ragazzi REST che dicono che alcuni esempi non sono "REST-ful", ma poi rifiutano di dire come cambiare l'esempio per essere REST-ful.
      2012-02-01 19: 19: 02Z

    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 che cita la parte essenziale che avrebbe risposto alla tua domanda per la maggior parte:

    Scopri REST: un tutorial

      

    REST è uno stile di architettura 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   usa 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 diventa grande ora potrebbe alleviare alcuni sentimenti.

        
    45
    2019-02-14 16: 55: 02Z

    Che cos'è REST?

    REST in parole ufficiali, REST è uno stile architettonico costruito su alcuni principi che utilizzano gli attuali fondamentali "Web". Ci sono 5 fondamentali di base del web che sono 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 URI (Uniform Resource Identifiers), 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 è eseguita per rappresentazione
    • Principio 5: Sii senza stato
    38
    2014-07-31 17: 11: 49Z
    1. Che cosa significa Communication is Done by Representation?
      2019-03-10 21: 59: 38Z

    Vedo un sacco di risposte che dicono che mettere tutto sull'utente 123 alla risorsa "/utente /123" è RESTful.

    Roy Fielding, che ha coniato il termine, dice REST Le API devono essere guidate da un 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 è veramente RESTful. Un buon uso di HTTP, forse, forse no. Ma non RESTful. Deve venire dall'ipertesto.

        
    33
    2009-03-22 16: 36: 31Z
    1. così .... come sarebbe quell'esempio riposante? come cambieresti l'URL per renderlo riposante?
      2009-03-22 16: 49: 09Z
    2. hasen: l'utilizzo di una risorsa per tutte le operazioni potrebbe essere necessario per RESTfulness, ma non sufficiente .
      2009-03-22 17: 20: 17Z
    3. ok bene .. potresti spiegare ulteriormente? Qual è il punto di dire "no questi ragazzi hanno torto .. so cosa è giusto" senza dire quello che sai (o pensi) di avere ragione?
      2009-03-22 20: 55: 14Z
    4. Ho dato il link alla descrizione di Fielding. Pensavo di aver detto esattamente la diff rilevante alle altre risposte: deve essere guidata dall'ipertesto. Se "/user /123" deriva da una documentazione API fuori banda, allora non è RESTful. Se proviene da un identificatore di risorsa nel tuo ipertesto, allora lo è.
      2009-03-23 ​​02: 08: 07Z
    5. Oppure puoi usare un entry point come /users /e ti darà un elenco di risorse utente E l'URI per ognuna. Quindi le risorse sono individuabili e la navigazione è guidata da ipertesto.
      2009-07-20 17: 37: 18Z

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

    Il termine RESTful è stato creato perché ppl ha esaurito la parola REST chiamando la loro applicazione non REST come REST. Successivamente, anche il termine RESTful era esaurito. Oggigiorno stiamo parlando di API Web e API Hypermedia , perché la maggior parte delle cosiddette applicazioni REST non soddisfacevano la parte HATEOAS del vincolo di interfaccia uniforme.

    I vincoli REST sono i seguenti:

    1. architettura client-server

      Quindi non funziona con, ad esempio, socket PUB /SUB, è basato su REQ /REP.

    2. comunicazione senza stato

      Quindi il server non mantiene gli stati dei client. Ciò significa che non è possibile utilizzare il server per l'archiviazione della sessione laterale e che è necessario autenticare ogni richiesta. I tuoi clienti possono inviare intestazioni di autenticazione di base tramite una connessione crittografata. (Con le applicazioni di grandi dimensioni è difficile mantenere molte sessioni.)

    3. uso della cache se puoi

      Quindi non devi servire più volte le stesse richieste.

    4. interfaccia uniforme come contratto comune tra client e server

      Il contratto tra il client e il server non viene gestito dal server. In altre parole, il cliente 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 vocabri RDF, microformati, ecc.) descrivere la semantica delle diverse parti del corpo del messaggio. Per disaccoppiare la struttura IRI dal client, devi inviare collegamenti ipertestuali ai client in formati ipermediali come (HTML, JSON-LD, HAL, ecc.). Quindi un cliente può utilizzare i metadati (possibilmente relazioni di collegamento, vocaboli 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 capisce che attivando questo collegamento ipertestuale invierà l'ordine. attiva il collegamento ipertestuale e invia un messaggio POST https://example.com/api/v1/order con il corpo appropriato, dopodiché il servizio elabora il messaggio e risponde con il risultato con l'intestazione di stato HTTP corretta, ad esempio 201 - created con esito positivo. Per annotare i messaggi con metadati dettagliati la soluzione standard da utilizzare un formato RDF, ad esempio JSON-LD con un vocabolario REST, ad esempio Hydra e vocab specifici del dominio come schema. org o qualsiasi altro vocab di dati collegati e forse un vocabolario specifico per applicazioni personalizzate, se necessario Ora questo non è facile, ecco perché la maggior parte usa HAL e altri semplici formati che di solito forniscono solo un vocabolario REST, ma nessun supporto dati collegato.

    5. crea un sistema a livelli 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. Quindi puoi aggiungere nuovi layer e componenti senza sforzo.

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

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

      Questo vincolo è facoltativo. Ad esempio puoi inviare un parser per un tipo di media specifico al client, e così via ... Per fare questo potresti aver bisogno di un sistema di caricatore di plugin standard nel client, o il tuo client sarà accoppiato alla soluzione del 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 vocab, quindi possono capirsi a vicenda nonostante il cliente non conosca i dettagli di implementazione del servizio. Ciò rende possibile creare clienti automatizzati che possono trovare e utilizzare i servizi REST per raggiungere i loro obiettivi. A lungo termine questi clienti possono comunicare tra loro e fidarsi l'uno dell'altro con compiti, proprio come fanno gli umani. Se aggiungiamo modelli di apprendimento a tali client, il risultato sarà uno o più AI che utilizzano il web delle macchine invece di un singolo parco server. Quindi alla fine il sogno di Berners Lee: il web semantico e l'intelligenza artificiale saranno realtà. Quindi nel 2030 finiamo con lo Skynet. Fino ad allora ...; -)

        
    26
    2014-09-19 01: 30: 46Z

    RESTful (programmazione dello stato del trasferimento) La programmazione API sta scrivendo applicazioni Web in qualsiasi linguaggio di programmazione seguendo 5 software di base stile architettonico principi:

    1. Risorsa (dati, informazioni).
    2. Identificatore globale univoco (tutte le risorse sono identificate da URI ).
    3. Interfaccia uniforme - usa l'interfaccia semplice e standard (HTTP).
    4. Rappresentazione - tutte le comunicazioni sono fatte per rappresentazione (ad es. XML /JSON )
    5. Stateless (ogni richiesta si verifica in completo isolamento, è più facile memorizzare nella cache e caricare il bilancio),

    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 è niente che usi le funzionalità attuali del web in modo semplice ed efficace (architettura di successo, collaudata e distribuita). È un'alternativa a piùmeccanismi complessi come SOAP , CORBA e RPC .

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

        
    21
    2014-06-15 19: 08: 26Z

    Se dovessi ridurre la tesi originale su REST a sole 3 frasi brevi, penso che la seguente cattura la sua essenza:

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

    Dopodiché, è facile cadere nei dibattiti su adattamenti, convenzioni di codifica e best practice.

    È interessante notare che non si fa menzione delle operazioni HTTP POST, GET, DELETE o PUT nella tesi. Questa deve essere l'interpretazione successiva di qualcuno di una "migliore pratica" 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 un sovraccarico considerevole e probabilmente una complessità non necessaria all'interfaccia. Richiedono inoltre ulteriori framework e strumenti di sviluppo per implementarli. Non sono sicuro che REST sia il termine migliore per distinguere tra interfacce di senso comune e interfacce progettate in modo eccessivo come WSDL e SOAP. Ma abbiamo bisogno di qualcosa.

        
    17
    2012-02-01 17: 23: 09Z

    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 è come dire che hai costruito una casa in uno stile particolare: ad esempio Tudor o Vittoriano. Sia REST che uno stile software e Tudor o Victorian come stile di casa possono essere definiti dalle qualità e dai vincoli che li compongono. Ad esempio, REST deve avere una separazione Client Server in cui i messaggi sono auto-descrittivi. Case stile Tudor hanno timpani sovrapposti e tetti che sono ripidamente inclinati con frontoni frontali. Puoi leggere la tesi di Roy per saperne di più sui vincoli e le qualità che costituiscono REST.

    REST a differenza degli stili domestici ha avuto difficoltà a essere applicato in modo coerente e pratico. Questo potrebbe essere stato intenzionale. Lasciando la sua effettiva implementazione al designer. Quindi sei libero di fare quello che vuoi fintanto che rispetti i vincoli esposti nella tesi che stai creando REST Systems.

    Bonus:

    L'intero web è basato su REST (o REST era basato sul web). Pertanto, come sviluppatore web, potresti volerlo sapere anche se non è necessario scrivere buone app web.

        
    17
    2012-02-01 21: 20: 21Z

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

    REST (Representational State Transfer) è un'architettura di progettazione che descrive come le risorse di rete (ovvero i nodi che condividono le informazioni) sono progettate e indirizzate. In generale, un'architettura RESTful fa in modo 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 torna indietro senza bisogno di sapere nulla del cliente. Ok, bello ... ma come lo facciamo in pratica?

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

    • Ma per trovare qualsiasi risorsa data e poi dire al client dove questa risorsa lIve, ci deve essere un modo universale di puntare alle risorse. È qui che entrano gli URI (Universal Resource Identifiers); sono fondamentalmente indirizzi univoci per trovare le risorse.

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

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

    • Per facilitare ulteriormente lo sforzo sul nostro server di ripetere i calcoli che sono già stati effettuati di recente per un determinato client, REST consente anche la memorizzazione nella cache. In sostanza, il caching significa scattare un'istantanea della risposta iniziale fornita al cliente. Se il client esegue nuovamente la stessa richiesta, il server può fornire al client lo snapshot anziché ripetere tutti i calcoli necessari per creare la risposta iniziale. Tuttavia, poiché è un'istantanea, se lo snapshot non è scaduto - il server imposta in anticipo una data di scadenza - e la risposta è stata aggiornata dalla cache iniziale (ovvero la richiesta fornirebbe una risposta diversa dalla risposta memorizzata nella cache) , il client non vedrà gli aggiornamenti fino alla scadenza della cache (o alla cancellazione della cache) e la risposta verrà nuovamente eseguita da zero.

    • L'ultima cosa che farai spesso qui sulle architetture RESTful è che sono sovrapposte. In realtà abbiamo già discusso implicitamente di 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 trasmette 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, client e server interagiscono tramite GET, POST, PUT, DELETE, ecc., Che fanno parte del linguaggio universale e le risorse possono essere indirizzate all'utilizzo di URL.

        
    17
    2017-04-14 01: 27: 55Z

    Penso che il punto di riposo sia la separazione dello stato in uno strato superiore mentre si usa 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. Riguardo ai 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 anche essere raggiunta a livello di piattaforma o di sistema, indipendentemente dalla lingua. Il riposante potrebbe essere visto come una delle soluzioni che ha avuto molto successo nella pratica corrente.

    Con uno stile rilassante, ottieni e manipola lo stato dell'applicazione su un Internet inaffidabile. Se fallisce l'operazione corrente per ottenere lo stato corretto e attuale, ha bisogno del principio di validazione zero per aiutare 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 riposo non è di per sé una soluzione completa, ha bisogno delle funzioni in altre parti dello stack di applicazioni Web per supportare il suo funzionamento.

    Dato questo punto di vista, lo stile di riposo non è realmente legato a Internet o all'applicazione web. È una soluzione fondamentale per molti professionistisituazioni di grammatica. Non è nemmeno semplice, rende l'interfaccia davvero semplice e affronta incredibilmente bene altre tecnologie.

    Solo il mio 2c.

    Modifica: due aspetti più importanti:

    15
    2018-04-30 16: 18: 25Z
    1. Un punto di vista MVC : il blog Resta le peggiori pratiche suggerito di non confondere modelli e risorse . Il libro Two Scoops of django suggerisce che l'API Rest sia il punto di vista e non per unire la logica di business alla vista. Il codice dell'app deve rimanere nell'app.
      2015-06-25 06: 20: 37Z
    2. 2015-06-25 15: 14: 56Z

    Questa è una "discussione" incredibilmente lunga e tuttavia abbastanza confusa per non dire altro.

    IMO:

    1) Non esiste una cosa come una programmazione riposante, senza un grosso giunto e tanta birra:)

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

    È possibile riepilogare (significativamente) i vincoli a:

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

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

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

    Per esempio link: è bello avere un'API bellissima, ma alla fine il client /server non si preoccupa veramente dei collegamenti che ottieni /invia è il contenuto che conta.

    Alla fine qualsiasi client RESTful dovrebbe essere in grado di consumare qualsiasi servizio RESTful purché il formato del contenuto sia noto.

        
    14
    2017-01-24 10: 54: 26Z

    Vecchia domanda, nuovo modo di rispondere. C'è un sacco di malinteso 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 è un professionista riposantegrammazione
    3. La programmazione RESTful non è per le API

    Definisco programmazione riposante come

      

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

    Per essere un programmatore riposante, devi provare a creare applicazioni che consentano agli attori di fare cose. Non solo esporre 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 che cos'è un controllo e cosa no e come eseguire un controllo. IE se i browser non conoscessero i tag <form> in html, non ci sarebbe nulla per te da inviare allo stato di transizione nel tuo browser.

    Non cerco di autopromuovermi, ma approfondisco queste idee in modo molto approfondito nel mio talk http://techblog.bodybuilding.com/2016/01/video-what-is-restful-200.html .

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

     modello di maturità richardson annotato

        
    12
    2019-02-28 09: 03: 54Z

    REST === L'analogia HTTP non è corretta fino a quando non sottolinei il fatto che "DEVE" essere HATEOAS guidato.

    Roy stesso l'ha cancellato qui .

    Un'API REST deve essere inserita senza alcuna conoscenza precedente oltre l'URI iniziale (segnalibro) e set di tipi di supporti standardizzati appropriati per il pubblico previsto (vale a dire, che 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 del 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.]

        
    11
    2017-08-23 10: 00: 00Z
    1. non risponde alla domanda come wel come gli altri, ma +1 per le informazioni che sono rilevanti!
      2017-10-02 19: 06: 25Z
    2. Penso che questo risponda anche alla domanda, ma ad esempio manca l'apolidia. Ogni vincolo è importante ... La parte del tipo di supporto standard non è sempre vera. Voglio dire ci sono strati di comprensione. Ad esempio se si utilizza RDF, quindi il tipo di supporto può essere compreso, ma il significato del contenuto no. Quindi il cliente ha bisogno di conoscere anche il vocabolario. Alcune persone stanno sperimentando questo tipo di API REST e un vocab REST generale per descrivere collegamenti ipertestuali, ecc. hydra-cg. it
      2018-12-08 08: 08: 31Z

    REST definisce 6 vincoli architettonici che rendono qualsiasi servizio Web - una vera API RESTful .

    1. Interfaccia uniforme
    2. Client-server
    3. Stateless
    4. Cachebile
    5. Sistema a strati
    6. Codice su richiesta (facoltativo)

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

        
    11
    2017-10-02 21: 23: 50Z
    1. Fielding added alcune ulteriori regole API /client RESTful devono aderire
      2017-10-02 22: 09: 46Z
      

    REST è uno stile architettonico basato sugli standard web e il 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 è disponibile un server REST   accesso alle risorse. Un client REST può accedere e modificare il REST   risorse.

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

    REST consente alle risorse di avere rappresentazioni diverse, ad esempio 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 seguente tabella fornisce una spiegazione di queste operazioni.

    • GET definisce un accesso alla lettura della risorsa senza effetti collaterali. La risorsa non viene mai modificata tramite una richiesta GET, ad esempio 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 risultati diversi.
    • POST aggiorna una risorsa esistente o crea una nuova risorsa.
    11
    2018-05-26 18: 08: 53Z
    1. Diverse virgolette, ma non una singola fonte menzionata. Dove l'hai preso?
      2018-12-13 19: 02: 30Z

    REST sta per Trasferimento dello stato di rappresentanza .

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

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

    Introduzione sul resto

        
    10
    2014-11-10 13: 37: 27Z

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

        
    10
    2014-12-06 06: 54: 24Z

    Non esiste tale nozione come "programmazione RESTful" di per sé. Sarebbe meglio chiamare il paradigma RESTful o anche l'architettura RESTful migliore. Non è un linguaggio di programmazione. È un paradigma.

    Da Wikipedia :

      

    Nel calcolo, il trasferimento dello stato di rappresentazione (REST) ​​è un   stile architettonico utilizzato per lo sviluppo web.

        
    10
    2016-08-26 20: 35: 59Z

    Il punto di riferimento è che se accettiamo di utilizzare 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 di intestazioni di cache per implementare memorizzazione nella cache a tutti i 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 la fonte aggiornata e più facilmente disponibile.

    Dire che Rest è solo un cambiamento sintattico dall'usare le richieste GET con un parametro di azione all'utilizzo dei verbi http disponibili fa sembrare che non abbia benefici ed è puramente cosmetico. Il punto è usare un linguaggio che possa essere compreso e ottimizzato da ogni parte della catena. Se l'operazione GET ha un'azione con effetti collaterali, devi saltare tutta la memorizzazione nella cache HTTP o finirai con risultati incoerenti.

        
    9
    2012-02-01 23: 52: 15Z
    1. "Dire che il riposo è solo un cambiamento sintattico ... fa sembrare che non ha benefici ed è puramente cosmetico" --- questo è esattamente il motivo per cui sto leggendo le risposte qui su SO. Nota che non hai spiegato, perché REST non è puramente cosmetico.
      2013-10-08 17: 14: 47Z

    Che cos'è Test API ?

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

    API REST

    REST: trasferimento dello stato di rappresentanza.

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

    4 Metodi API comunemente usati: -

    1. RICEVI: - Fornisce 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. DELETE: - Viene utilizzato per rimuovere una risorsa.

    Passaggi per testare manualmente l'API: -

    Per utilizzare manualmente le API, possiamo utilizzare 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 contenuto-Intestazione
    5. Inserisci richiesta JSON (POST)
    6. Fai clic su invia
    7. Restituisce la risposta in uscita ​​li>

    Passi per automatizzare l'API REST

        
    5
    2016-08-01 12: 18: 53Z
    1. questa non è nemmeno una risposta appropriata ​​div>
      2016-08-05 07: 17: 26Z

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

      Modello di maturità di Richardson

          
      5
      2017-08-29 11: 55: 15Z
      1. Se si osservano i vincoli Fielding put su REST si vedrà chiaramente che un'API deve aver raggiunto il Layer 3 dell'RMM per poter essere visualizzata come RESTful, sebbene questo semplicemente non è abbastanza perché ci sono ancora abbastanza possibilità per fallire l'idea REST - il disaccoppiamento dei client dalle API del server. Certo, il livello 3 soddisfa il vincolo HATEOAS ma è ancora facile rompere i requisiti e accoppiare strettamente i client a un server (cioè utilizzando risorse tipizzate)
        2017-10-02 22: 21: 52Z

      Direi che un elemento fondamentale nella comprensione di REST si trova negli endpoint o nei mapping, come /customers/{id}/balance.

      È possibile immaginare un simile 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 mappatura REST nella propria applicazione.

          
      2
      2019-03-27 10: 11: 45Z
fonte posta Qui