BE 1.11 REST
Table of contents
REST (REpresentational State Transfer) är en samling konventioner för hur API:er ska utformas och fungera. Det är inget system i sig utan handlar om regler. Följer vi reglerna så är API:et RESTful, annars inte. REST underlättar vid dokumentation och förståelse för andra utvecklare.
API
API = Application Program(ming) Interface.
API:er används till i princip allting när det kommer till tjänster online.De är lite som en mellanhand mellan klient och server. Klienten gör förfrågningar till servern/databasen via API:er. Olika applikationer kan göra förfrågningar och få samma svar.
- Access - vem får begära info
- Request - vad för data och tjänster kan frågas
- Methods - vilka typer av frågor och svar
- Parameters - övriga detaljer som inkluderas i frågan
- Response - datan eller tjänsten vi frågade efter
Med detta kommer också ett behov att strukturera och formalisera kommunikationen.
- Hur skrivs en request/förfrågan?
- Hur tas svaret emot?
- Vilket format är svaret i?
- Hur ser det ut?
Här kommer REST in.
Konventioner i REST
- Separation av klient och server
- Klient och server ska vara oberoende av varann
- Klienten ska kunna bytas ut, och det ska kunna gå att få samma svar
- Ska inte vara beroende av en specfik databas
- Frontend och backend (API) kan utvecklas oberoende av varandra
- Sitter de ihop mer blir det svårt att till exempel byta server
- Ändras koden i frontend så påverkas inte backend och vice versa
- Så länge varje sida vet hur meddelanden ska formatteras och skickas och få samma svar, så kan de hållas isär
- I REST kan olika klienter träffa samma URI:er i ett och samma API och få samma svar
- Statelessness
- API:er som följer REST är stateless
- Servern behöver inte veta vilket tillstånd applikationen är i
- Varje fråga från klient till server måste innehålla all information som behövs för att få rätt svar
- Användarsession och sessioninformation -> klientens uppgift
- Svar ska gå att cacha
- Ställer du en fråga och får ett svar så ska det kunna cachas och finnas kvar, så länge svaret inte ändras (och ändras det så ska du få reda på det)
- Uniformt interface
- Identifiering av resureser
- Manipulation av resurser
- Självbeskrivande meddelanden
- Länka resurser med varann
Mer om uniformt interface
Identifiering av resureser
Saker = resurser. Sånt vi behöver kunna spara ner och hämta upp. Allt som finns i databasen är en sorts resurs.
Inte REST:
- GET /get article?id=1
- POST /delete article id=1
REST:
- GET /articles/1/
- DELETE /articles/1/
Manipulation av resurser
Hur vi skriver med nyckelord etc, använder oss av de definerade nyckelorden (HTTP-verben) t.ex. GET, POST, PUT, DELETE.
Beroende på HTTP-verb (representation) så får vi olika former och händelser på resurser. T.ex. om vi gör en GET-förfrågan på alla resurser/saker i en tabell så får vi upp alla, gör vi med ett visst id får vi upp just den resursen etc.
Inte REST:
- browser: /showPosts.php?format=html
- application: /showPosts.php?format=json
REST:
- browser: “I want /posts/7/, please give me HTML.”
- application: “I want /posts/7/, please give me JSON.”
Självbeskrivande meddelanden
Svaret ska gå att förstå sig på. Får du en error ska du förstå den, om inte ska du få ett relevant svar för frågan.
Ska innehålla både status (HTTP) och svarsdatan på förfrågan i lämpligt format. Lämpligt format är absolut oftast JSON. Request-responset ska vara i JSON, veta hur det gick för requesten.
Inte REST:
/search=results?q=post
/search=results?page=2
/search=results?page=3
REST:
/search=results?q=post
/search=results?q=post&page=2
/search=results?q=post&page=3
Länka resurser med varann
- Till exempel om en användare har gjort inlägg på en sida, hur den relationen ser ut.
- Paginering i långa resultat, går inte att typ hämta hela databasen på en gång.
Inte REST:
/posts/7/
{
"name": "Mina blogginlägg",
"items": [35, 36]
}
REST:
/posts/7/
{
"name": "Mina blogginlägg",
"items": ["/posts/7/category/35/", "/posts/7/category/36/"]
}