REST (Representational State Transfer) je arhitekturni slog za omrežne aplikacije, ki ga je opredelil Roy Fielding. Ni protokol ali standard — je nabor omejitev (constraints), ki, kadar jih upoštevamo, naredijo API razširljiv, predpomnljiv in enostaven za razvoj. "RESTful" API vse modelira kot vire (resources) (uporabnike, naročila, izdelke), identificirane z URI-ji, in z njimi upravlja s standardnimi metodami HTTP.
GET /users/42 HTTP/1.1
Host: api.example.com
Accept: application/json
HTTP/1.1 200 OK
Content-Type: application/json
{ "id": 42, "name": "Ann", "email": "[email protected]" }
URI /users/42 poimenuje vir; GET je dejanje; JSON je predstavitev. Ta kombinacija — samostalniki v poti, glagoli kot metode HTTP — je srce REST-a.
REST je prevladujoč slog za spletne API-je, zato spraševalci s tem vprašanjem preverijo, ali razumete, zakaj deluje, ne le, da ga znate izgovoriti. Dve najpomembnejši omejitvi v praksi sta statelessness (vsaka zahteva je samozadostna, zato lahko za izenačevalnik obremenitve postavite poljubno število strežnikov in skalirate horizontalno brez sticky sej) in uniform interface (predvidljivi, v vire usmerjeni URL-ji plus standardne metode HTTP in status kode, kar pomeni, da odjemalci ne potrebujejo logike po meri za vsak endpoint). Močan odgovor poveže omejitve s konkretnimi koristmi — statelessness omogoča skaliranje, cacheability zmanjša obremenitev, layered system omogoča vstavljanje CDN-jev in prehodov — in opozori, da je večina "REST" API-jev pragmatičnih in ne povsem RESTful (redki implementirajo HATEOAS). Razumevanje teh omejitev je temelj za vsako drugo odločitev pri načrtovanju REST-a, od izbire status kod do versioninga.
Knjižnica IT vprašanj za razgovore s podrobnimi odgovori — od začetnika do izkušenega.
Doniraj