Hva er egentlig RESTful-programmering?

REST er det underliggende arkitekturprinsippet for nettet. Det fantastiske med nettet er at klienter (nettlesere) og servere kan samhandle på komplekse måter uten at klienten vet noe på forhånd om serveren og ressursene den er vert for. Den viktigste begrensningen er at serveren og klienten begge må være enige om mediet som brukes, som i webens tilfelle er HTML.

Et API som følger prinsippene for REST krever ikke at klienten vet noe om strukturen til API-et. Tvert imot må serveren gi den informasjonen klienten trenger for å samhandle med tjenesten. Et HTML-skjema er et eksempel på dette: Serveren angir plasseringen av ressursen og de nødvendige feltene. Nettleseren vet ikke på forhånd hvor informasjonen skal sendes, og den vet ikke på forhånd hvilken informasjon som skal sendes. Begge former for informasjon leveres i sin helhet av serveren (Dette prinsippet kalles HATEOAS: Hypermedia As The Engine Of Application State.)

Så hvordan gjelder dette for HTTP, og hvordan kan det implementeres i praksis? HTTP er orientert rundt verb og ressurser. De to verbene i vanlig bruk er GET og POST, som jeg tror alle vil kjenne igjen. HTTP-standarden definerer imidlertid flere andre, for eksempel PUT og DELETE. Disse verbene brukes deretter på ressurser, i henhold til instruksjonene fra serveren.

La oss for eksempel tenke oss at vi har en brukerdatabase som administreres av en webtjeneste. Tjenesten vår bruker et egendefinert hypermedia basert på JSON, som vi tilordner mimetypen application/json+userdb (det kan også være en application/xml+userdb og application/whatever+userdb - mange medietyper kan støttes). Klienten og serveren er begge programmert til å forstå dette formatet, men de vet ikke noe om hverandre. Som Roy Fielding påpeker:

Et REST API bør bruke nesten all sin beskrivende innsats på å å definere medietypen(e) som brukes til å representere ressurser og drive applikasjonsstatus, eller i å definere utvidede relasjonsnavn og/eller hypertekst-aktivert markering for eksisterende standard medietyper.

En forespørsel etter basisressursen / kan returnere noe slikt som dette:

Forespørsel

GET /
Accept: application/json+userdb

Svar

200 OK
Content-Type: application/json+userdb

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

Vi vet fra beskrivelsen av mediene våre at vi kan finne informasjon om relaterte ressurser fra seksjoner som kalles "lenker". Dette kalles Hypermediakontroller. I dette tilfellet kan vi se fra en slik seksjon at vi kan finne en brukerliste ved å gjøre en ny forespørsel etter /user:

Forespørsel.

GET /user
Accept: application/json+userdb

Svar

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

Vi kan fortelle mye fra dette svaret. For eksempel vet vi nå at vi kan opprette en ny bruker ved å POSTe til /user:

Forespørsel

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

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

Svar

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

Vi vet også at vi kan endre eksisterende data:

Forespørsel

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

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

Svar

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

Legg merke til at vi bruker forskjellige HTTP-verb (GET, PUT, POST, DELETE osv.) for å manipulere disse ressursene, og at den eneste kunnskapen vi forutsetter hos klienten er vår mediodefinisjon.

Videre lesing:

• De mange mye bedre svarene på denne siden.
• Hvordan jeg forklarte REST til min kone.
• Hvordan jeg forklarte REST til min kone.
• Martin Fowlers tanker
• PayPals API har hypermediakontroller

(Dette svaret har vært gjenstand for en god del kritikk for å bomme på poenget. For det meste har det vært en rettferdig kritikk. Det jeg opprinnelig beskrev var mer i tråd med hvordan REST vanligvis ble implementert for noen år siden da jeg først skrev dette, snarere enn den sanne betydningen. Jeg har revidert svaret for å bedre representere den virkelige betydningen).

REST bruker de ulike HTTP-metodene (hovedsakelig GET/PUT/DELETE) for å manipulere data.

I stedet for å bruke en spesifikk URL for å slette en metode (for eksempel /user/123/delete), sender du en DELETE-forespørsel til /user/[id]-URL-en for å redigere en bruker, for å hente informasjon om en bruker sender du en GET-forespørsel til /user/[id].

For eksempel, i stedet et sett med URL-er som kan se ut som noen av de følgende....

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

Du bruker HTTP "verb" og har...

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

Det er programmering der arkitekturen til systemet ditt passer til REST-stilen lagt ut av Roy Fielding i hans avhandling. Siden dette er den arkitektoniske stilen som beskriver nettet (mer eller mindre), er mange mennesker interessert i den.

Bonussvar: Med mindre du studerer programvarearkitektur som akademiker eller designer webtjenester, er det egentlig ingen grunn til å ha hørt begrepet.