REST eller RESTful API design (Representational State Transfer) är utformad för att dra nytta av befintliga protokoll. Medan resten kan användas över nästan alla protokoll, det brukar dra nytta av HTTP när den används för webb API. Detta innebär att utvecklare inte behöver installera bibliotek eller ytterligare programvara för att dra nytta av en REST API-design. REST API Design definierades av Dr. Roy Fielding i sin 2000 doktorsavhandling. Det är anmärkningsvärt för sitt otroliga lager av flexibilitet., Eftersom data inte är knutna till metoder och resurser har REST möjlighet att hantera flera typer av samtal, returnera olika dataformat och till och med förändras strukturellt med korrekt genomförande av hypermedia.
denna frihet och flexibilitet som är inneboende i REST API-design gör att du kan bygga ett API som uppfyller dina behov samtidigt som du uppfyller behoven hos mycket olika kunder. Till skillnad från SOAP är REST inte begränsad till XML, men kan istället returnera XML, JSON, YAML eller något annat format beroende på vad klienten begär., Och till skillnad från RPC behöver användarna inte känna till procedurnamn eller specifika parametrar i en viss ordning.
det finns dock nackdelar med REST API-design. Du kan förlora förmågan att behålla tillståndet i vila, till exempel inom sessioner, och det kan vara svårare för nyare utvecklare att använda. Det är också viktigt att förstå vad som gör en REST API vilsam, och varför dessa begränsningar finns innan du bygger ditt API. När allt kommer omkring, om du inte förstår varför något är utformat på det sätt det är, kan du hindra dina ansträngningar utan att ens inse det.,
förstå REST API Design
medan de flesta API: er hävdar att de är vilsamma, faller de under de krav och begränsningar som Dr.Fielding hävdar. Det finns sex viktiga begränsningar för REST API-design att vara medveten om när man bestämmer om detta är rätt API-typ för ditt projekt.
Client-Server
Client-server constraint fungerar på konceptet att klienten och servern ska vara separata från varandra och får utvecklas individuellt och självständigt., Med andra ord borde jag kunna göra ändringar i min mobilapplikation utan att påverka datastrukturen eller databasdesignen på servern. Samtidigt borde jag kunna ändra databasen eller göra ändringar i min serverprogram utan att påverka mobilklienten. Detta skapar en separation av oro, låta varje ansökan växa och skala oberoende av den andra och låta din organisation att växa snabbt och effektivt.,
statslösa
REST API: er är statslösa, vilket innebär att samtal kan göras oberoende av varandra, och varje samtal innehåller alla data som behövs för att slutföra sig framgångsrikt. Ett REST API bör inte förlita sig på data som lagras på servern eller sessioner för att avgöra vad man ska göra med ett samtal, utan snarare enbart förlita sig på de data som tillhandahålls i själva samtalet. Identifieringsinformation lagras inte på servern när du ringer. I stället har varje samtal de nödvändiga uppgifterna i sig, till exempel API-nyckeln, åtkomsttoken, användar-ID etc., Detta bidrar också till att öka API: s tillförlitlighet genom att ha alla data som behövs för att ringa samtalet, istället för att förlita sig på en serie samtal med serverstatus för att skapa ett objekt, vilket kan leda till partiella fel. I stället, för att minska minneskraven och hålla din ansökan så skalbar som möjligt, kräver en vilsam API att någon stat lagras på klienten—inte på servern.
Cache
eftersom en statslös API kan öka begäran overhead genom att hantera stora mängder inkommande och utgående samtal, en REST API bör utformas för att uppmuntra lagring av cachelagrade data., Detta innebär att när data cachelagras, bör svaret indikera att data kan lagras upp till en viss tid (upphör att gälla), eller i de fall där data behöver vara i realtid, att svaret inte ska cachas av kunden. Genom att aktivera denna kritiska begränsning, kommer du inte bara kraftigt minska antalet interaktioner med din API, minska intern serveranvändning, men också ge dina API-användare med de verktyg som behövs för att ge de snabbaste och mest effektiva program som möjligt. Tänk på att caching görs på klientsidan., Även om du kanske kan cache vissa data inom din arkitektur för att utföra övergripande prestanda, är avsikten att instruera kunden om hur det ska gå och om klienten kan lagra data tillfälligt.
enhetligt gränssnitt
nyckeln till frikopplingsklienten från servern har ett enhetligt gränssnitt som möjliggör oberoende utveckling av programmet utan att ha programmets tjänster, modeller eller åtgärder tätt kopplade till själva API-skiktet., Det enhetliga gränssnittet låter klienten prata med servern på ett enda språk, oberoende av den arkitektoniska backend av antingen. Detta gränssnitt bör ge ett oföränderligt, standardiserat sätt att kommunicera mellan klienten och servern, till exempel att använda HTTP med Uri-resurser, CRUD (skapa, läsa, uppdatera, ta bort) och JSON.
skiktat System
som namnet antyder är ett skiktat system ett system bestående av lager, där varje lager har en specifik funktionalitet och ansvar., Om vi tänker på en modell View Controller ram, varje lager har sitt eget ansvar, med de modeller som omfattar hur data ska bildas, styrenheten med fokus på inkommande åtgärder och vyn med fokus på produktionen. Varje lager är separat men interagerar också med den andra. I REST API-design håller samma princip sant, med olika lager av arkitekturen som arbetar tillsammans för att bygga en hierarki som hjälper till att skapa en mer skalbar och modulär applikation.,
ett skiktat system låter dig också inkapsla äldre system och flytta mindre allmänt åtkomlig funktionalitet till en delad mellanhand samtidigt som du skyddar mer moderna och vanliga komponenter från dem. Dessutom ger det skiktade systemet dig friheten att flytta system in och ut ur din arkitektur som teknik och tjänster utvecklas, vilket ökar flexibiliteten och livslängden så länge du håller de olika modulerna så löst kopplade som möjligt., Det finns betydande säkerhetsfördelar med att ha ett skiktat system eftersom det tillåter dig att stoppa attacker på proxylagret, eller inom andra lager, förhindra dem från att komma till din faktiska server arkitektur. Genom att använda ett skiktat system med en proxy, eller skapa en enda åtkomstpunkt, kan du hålla kritiska och mer sårbara aspekter av din arkitektur bakom en brandvägg, förhindra direkt interaktion med dem av klienten., Tänk på att säkerheten inte är baserad på en enda ”stoppa alla” lösning, utan snarare på att ha flera lager med insikten att vissa säkerhetskontroller kan misslyckas eller kringgås. Som sådan, ju mer säkerhet Du kan implementera i ditt system, desto mer sannolikt är du att förhindra skadliga attacker.
Code on Demand
kanske den minst kända av de sex begränsningarna, och den enda frivilliga begränsningen, Code on Demand tillåter att kod eller applets överförs via API för användning i programmet., I huvudsak skapar det en smart applikation som inte längre är enbart beroende av sin egen kodstruktur. Men kanske för att det är före sin tid har Code on Demand kämpat för adoption eftersom webb API: er konsumeras på flera språk och överföringen av kod väcker säkerhetsfrågor och oro. (Till exempel måste katalogen vara skrivbar,och brandväggen måste låta vad som normalt kan vara begränsat innehåll genom.)
tillsammans utgör dessa begränsningar teorin om Representationsstatsöverföring eller vila., När du tittar tillbaka genom dessa kan du se hur varje successiv begränsning bygger ovanpå den tidigare, så småningom skapa en ganska komplex – men kraftfull och flexibel—programgränssnitt. Men viktigast av allt, dessa begränsningar utgör en design som fungerar på samma sätt som hur vi kommer åt sidor i våra webbläsare på World Wide Web. Det skapar ett API som inte dikteras av dess arkitektur, men av de representationer som den returnerar, och ett API som-medan arkitektoniskt statslös-bygger på representationen att diktera programmets tillstånd.,
För mer information om VILA API-Design, kolla in eBook Ostörd VILA: EN Guide till att Utforma den Perfekta API.
Lämna ett svar