REST (Representational State Transfer) er en arkitekturstil for netværksapplikationer, defineret af Roy Fielding. Det er ikke en protokol eller standard — det er et sæt constraints, der, når de følges, gør en API skalerbar, cachebar og let at videreudvikle. En "RESTful" API modellerer alt som resources (users, orders, products) identificeret ved URI'er og manipulerer dem ved hjælp af standard-HTTP-methods.
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'en /users/42 navngiver resourcen; GET er handlingen; JSON er representationen. Den kombination — navneord i path'en, udsagnsord som HTTP-methods — er kernen i REST.
REST er den dominerende stil for web-APIs, så interviewere bruger dette spørgsmål til at tjekke, at du forstår hvorfor det virker, ikke bare at du kan stave til det. De to constraints, der betyder mest i praksis, er statelessness (hver request er selvstændig, så du kan sætte et vilkårligt antal servere bag en load balancer og skalere horisontalt uden sticky sessions) og uniform interface (forudsigelige, resource-orienterede URL'er plus standard-HTTP-methods og status-koder, hvilket betyder, at clients ikke behøver custom-logik per endpoint). Et stærkt svar forbinder constraints med konkrete fordele — statelessness muliggør skalering, cacheability reducerer belastning, det layered system lader dig indsætte CDN'er og gateways — og bemærker, at de fleste "REST"-APIs er pragmatiske frem for fuldt RESTful (få implementerer HATEOAS). At forstå disse constraints er fundamentet for enhver anden REST-designbeslutning, fra valg af status-koder til versionering.
Et bibliotek af IT-interviewspørgsmål med detaljerede svar — fra Junior til Senior.
Donér