Cos'è esattamente la programmazione RESTful?

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 nulla in anticipo sul server e sulle risorse che ospita. Il vincolo chiave è che il server e il client devono essere entrambi d'accordo sul media usato, che nel caso del web è HTML.

Un'API che aderisce ai principi di REST non richiede che il client sappia nulla della struttura dell'API. Piuttosto, il server deve fornire qualsiasi informazione di cui il client ha bisogno per interagire con il servizio. Un formulario 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 questo a HTTP, e come può essere implementato in pratica? HTTP è orientato intorno a verbi e risorse. I due verbi di uso comune sono GET e POST, che penso tutti riconosceranno. Tuttavia, lo standard HTTP ne definisce molti altri come PUT e DELETE. Questi verbi vengono poi applicati alle risorse, secondo le istruzioni fornite dal server.

Per esempio, immaginiamo di avere un database di utenti gestito da un servizio web. Il nostro servizio usa un hypermedia personalizzato basato su JSON, per il quale assegniamo il mimetype application/json+userdb (potrebbe esserci anche un application/xml+userdb e application/whatever+userdb - molti tipi di media possono essere supportati). Il client e il server sono stati entrambi programmati per capire questo formato, ma non sanno nulla l'uno dell'altro. Come sottolinea Roy Fielding:

Una API REST dovrebbe spendere quasi tutto il suo sforzo descrittivo in definendo il tipo(i) di media usati per rappresentare le risorse e guidare lo stato dell'applicazione, o nel definire nomi di relazioni estese e/o mark-up ipertestuale per i tipi di media standard esistenti.

Una richiesta per la risorsa 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 su risorse correlate da sezioni chiamate "link". Questo si chiama Controlli ipermediali. In questo caso, possiamo dire da tale sezione che possiamo trovare una lista di 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 capire molto da questa risposta. Per esempio, ora sappiamo che possiamo creare un nuovo utente facendo 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 cambiare 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"
    }
}

Notate che stiamo usando diversi verbi HTTP (GET, PUT, POST, DELETE ecc.) per manipolare queste risorse, e che l'unica conoscenza che presumiamo da parte del client è la nostra definizione dei media.

Ulteriori letture:

• Le molte risposte molto migliori su questa stessa pagina.
• Come ho spiegato REST a mia moglie.
• Come ho spiegato REST a mia moglie.
• Martin Fowler's pensieri
• PayPal'API ha controlli ipermediali

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

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

Piuttosto che usare un URL specifico per eliminare un metodo (ad esempio, /user/123/delete), si dovrebbe inviare una richiesta DELETE all'URL /user/[id], per modificare un utente, per recuperare le informazioni su un utente si invia una richiesta GET a /user/[id]

Per esempio, invece un insieme di URL che potrebbe assomigliare ad 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

Si usano i "verbi" HTTP e si ha..

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

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

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