Wat is RESTful programmeren precies?

REST is het onderliggende architectuurprincipe van het web. Het verbazingwekkende van het web is het feit dat clients (browsers) en servers op complexe manieren met elkaar kunnen communiceren zonder dat de client van tevoren iets weet over de server en de bronnen die hij host. De belangrijkste beperking is dat de server en de client het beide eens moeten zijn over de gebruikte media, die in het geval van het web HTML is.

Een API die de principes van REST volgt, vereist niet dat de client iets weet over de structuur van de API. In plaats daarvan moet de server alle informatie verstrekken die de client nodig heeft om met de dienst te interageren. Een HTML-formulier is hier een voorbeeld van: De server specificeert de locatie van de bron en de vereiste velden. De browser weet niet van tevoren waar hij de informatie moet indienen, en hij weet niet van tevoren welke informatie hij moet indienen. Beide vormen van informatie worden volledig door de server aangeleverd. (Dit principe wordt HATEOAS: Hypermedia As The Engine Of Application State genoemd.)

Hoe is dit van toepassing op HTTP, en hoe kan het in de praktijk worden geïmplementeerd? HTTP is georiënteerd op werkwoorden en bronnen. De twee meest gebruikte werkwoorden zijn GET en POST, waarvan ik denk dat iedereen ze zal herkennen. Echter, de HTTP standaard definieert verschillende andere zoals PUT en DELETE. Deze werkwoorden worden dan toegepast op bronnen, volgens de instructies van de server.

Laten we ons bijvoorbeeld voorstellen dat we een gebruikersdatabase hebben die wordt beheerd door een webdienst. Onze service gebruikt een aangepaste hypermedia gebaseerd op JSON, waarvoor we het mimetype application/json+userdb toewijzen (Er kan ook een application/xml+userdb en application/whatever+userdb zijn - vele mediatypen kunnen worden ondersteund). De client en de server zijn beide geprogrammeerd om dit formaat te begrijpen, maar ze'weten niets van elkaar. Zoals Roy Fielding opmerkt:

Een REST API zou bijna al zijn beschrijvende inspanning moeten besteden aan het definiëren van de media type(s) die gebruikt worden voor het representeren van bronnen en het aansturen van applicatiestatus, of in het definiëren van uitgebreide relatienamen en/of hypertext-enabled mark-up voor bestaande standaard media types.

Een verzoek voor de basis resource / zou iets als dit kunnen opleveren:

Verzoek

GET /
Accept: application/json+userdb

Response

200 OK
Content-Type: application/json+userdb

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

Uit de beschrijving van onze media weten we dat we informatie over verwante bronnen kunnen vinden in secties genaamd "links". Dit wordt Hypermedia controls genoemd. In dit geval kunnen we uit zo'n sectie opmaken dat we een gebruikerslijst kunnen vinden door nog een request te doen naar /user:

Vraag

GET /user
Accept: application/json+userdb

Response

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

Uit dit antwoord kunnen we veel afleiden. Zo weten we nu bijvoorbeeld dat we een nieuwe gebruiker kunnen aanmaken door POSTing naar /user:

Request

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

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

Response

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

We weten ook dat we bestaande gegevens kunnen wijzigen:

Vraag

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

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

Response

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

Merk op dat we verschillende HTTP werkwoorden gebruiken (GET, PUT, POST, DELETE enz.) om deze bronnen te manipuleren, en dat de enige kennis die we veronderstellen van de kant van de client's onze media definitie is.

Verder lezen:

• De vele veel betere antwoorden op deze pagina.
• Hoe ik REST aan mijn vrouw uitlegde.
• Hoe ik REST aan mijn vrouw uitlegde.
• Martin Fowler's gedachten
• PayPal's API heeft hypermedia controles

(Op dit antwoord is nogal wat kritiek gekomen omdat het de kern van de zaak zou missen. Voor het grootste deel is dat terechte kritiek geweest. Wat ik oorspronkelijk beschreef was meer in overeenstemming met hoe REST gewoonlijk werd geïmplementeerd een paar jaar geleden toen ik dit voor het eerst schreef, in plaats van de ware betekenis ervan. Ik'heb het antwoord herzien om beter de echte betekenis weer te geven).

REST is het gebruik van de verschillende HTTP-methoden (hoofdzakelijk GET/PUT/DELETE) om gegevens te manipuleren.

In plaats van een specifieke URL te gebruiken om een methode te verwijderen (zeg, /user/123/delete), zou je een DELETE verzoek sturen naar de /user/[id] URL, om een gebruiker te bewerken, om info over een gebruiker op te halen stuur je een GET verzoek naar /user/[id]

Bijvoorbeeld, in plaats van een aantal URLs die er als volgt uit zouden kunnen zien...

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

Je gebruikt de HTTP "werkwoorden" en hebt...

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

Het is programmeren waarbij de architectuur van je systeem past in de REST-stijl die Roy Fielding in zijn proefschrift heeft uiteengezet. Aangezien dit de architectuurstijl is die het web (min of meer) beschrijft, zijn veel mensen erin geïnteresseerd.

Bonus antwoord: Nee. Tenzij je'als academicus softwarearchitectuur studeert of webdiensten ontwerpt, is er eigenlijk geen reden om van de term gehoord te hebben.