Kas īsti ir RESTful programmēšana?

Kas īsti ir RESTful programmēšana?

REST ir tīmekļa arhitektūras pamatprincips. Tīmekļa pārsteidzošā īpašība ir tā, ka klienti (pārlūkprogrammas) un serveri var mijiedarboties sarežģītos veidos, klientam iepriekš neko nezinot par serveri un tajā izvietotajiem resursiem. Galvenais ierobežojums ir tāds, ka serverim un klientam ir jāvienojas par izmantoto mediju, kas tīmekļa gadījumā ir HTML.

API, kas atbilst REST principiem, neprasa, lai klients kaut ko zinātu par API struktūru. Drīzāk serverim ir jāsniedz visa klientam nepieciešamā informācija, lai mijiedarbotos ar pakalpojumu. HTML veidlapa ir šāds piemērs: Serveris norāda resursa atrašanās vietu un nepieciešamos laukus. Pārlūkprogramma iepriekš nezina, kur iesniegt informāciju, un tā iepriekš nezina, kāda informācija tai jāiesniedz. Abus informācijas veidus pilnībā nodrošina serveris. (Šo principu sauc par HATEOAS: Hypermedia As The Engine Of Application State.).

Tātad, kā tas attiecas uz HTTP un kā to var īstenot praksē? HTTP ir orientēts uz darbības vārdiem un resursiem. Divi galvenie darbības vārdi ir GET un POST, kurus, manuprāt, visi atpazīs. Tomēr HTTP standartā ir definēti vairāki citi, piemēram, PUT un DELETE. Šie darbības vārdi tiek piemēroti resursiem saskaņā ar servera sniegtajiem norādījumiem.

Piemēram, iedomāsimies, ka mums ir lietotāju datubāze, ko pārvalda tīmekļa pakalpojums. Mūsu pakalpojums izmanto pielāgotu hipertīklu, kura pamatā ir JSON, kam mēs piešķiram mimetype application/json+userdb (var būt arī application/xml+userdb un application/whatever+userdb - var tikt atbalstīti daudzi mediju tipi). Gan klients, gan serveris ir ieprogrammēti tā, lai saprastu šo formātu, bet tie viens par otru neko nezina. Kā norāda Roy Fielding:

REST API gandrīz viss tā aprakstīšanas darbs būtu jāvelta tam, lai aprakstītu definējot multivides tipu(-us), ko izmanto, lai attēlotu resursus un vadītu lietojumprogrammas stāvokļa definēšanai vai paplašinātu attiecību nosaukumu un/vai > lietojumprogrammas stāvokļa definēšanai. hiperteksta marķējumu esošajiem standarta multivides tipiem.

Pieprasot bāzes resursu /, var saņemt kaut ko līdzīgu:

Pieprasījums

GET /
Accept: application/json+userdb

Atbilde

200 OK
Content-Type: application/json+userdb

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

No mūsu multivides apraksta mēs zinām, ka informāciju par saistītiem resursiem mēs varam atrast sadaļās ar nosaukumu "saites". To sauc par Hipermediju kontroli. Šajā gadījumā no šādas sadaļas mēs varam noteikt, ka varam atrast lietotāju sarakstu, veicot vēl vienu pieprasījumu /user:

Pieprasījums

GET /user
Accept: application/json+userdb

Atbilde

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

No šīs atbildes var daudz ko secināt. Piemēram, tagad mēs zinām, ka varam izveidot jaunu lietotāju, izmantojot POST uz /user:

Pieprasījums

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

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

Atbilde

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

Mēs arī zinām, ka varam mainīt esošos datus:

Pieprasījums

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

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

Atbilde

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

Ievērojiet, ka mēs izmantojam dažādus HTTP darbības vārdus (GET, PUT, POST, DELETE u.c.), lai manipulētu ar šiem resursiem, un ka vienīgās zināšanas, ko mēs pieņemam no klienta puses, ir mūsu mediju definīcija.

Turpmāka lasīšana:

(Šī atbilde ir saņēmusi diezgan daudz kritikas par to, ka tajā nav ietverta būtība. Lielākoties tā ir taisnīga kritika. Tas, ko es sākotnēji aprakstīju, vairāk atbilda tam, kā REST parasti tika īstenots pirms dažiem gadiem, kad es pirmo reizi to rakstīju, nevis tā patiesajai nozīmei. Esmu pārskatījis atbildi, lai labāk atspoguļotu patieso nozīmi.)

Komentāri (39)

REST izmanto dažādas HTTP metodes (galvenokārt GET/PUT/DELETE), lai manipulētu ar datiem.

Tā vietā, lai dzēstu metodi (piemēram, /user/123/delete), jūs nosūtītu DELETE pieprasījumu uz /user/[id] URL, lai rediģētu lietotāju, lai iegūtu informāciju par lietotāju, jūs nosūtītu GET pieprasījumu uz /user/[id].

Piemēram, tā vietā var izveidot URL kopumu, kas varētu izskatīties šādi..

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

Jūs izmantojat HTTP "verbs" un jums ir..

GET /user/2
DELETE /user/2
PUT /user
Komentāri (5)

Tā ir programmēšana, kurā jūsu sistēmas arhitektūra atbilst REST stilam, ko savā disertācijā izklāstījis Rojs Fildings. Tā kā šis arhitektūras stils (vairāk vai mazāk) raksturo tīmekli, tas interesē daudzus cilvēkus.

Bonusa atbilde: Ja vien jūs kā akadēmiskais darbinieks nestudējat programmatūras arhitektūru vai neizstrādājat tīmekļa pakalpojumus, nav iemesla dzirdēt šo terminu.

Komentāri (4)