Richardson Mognadsmodell
Richardson Maturity Model ( RMM ) är en mognadsmodell som föreslogs 2008 av Leonard Richardson och som klassificerar webb-API: er baserat på deras följsamhet och överensstämmelse med var och en av modellens fyra nivåer. Syftet med forskningen av modellen enligt författaren var att ta reda på sambandet mellan restriktioner för REST och andra former av webbtjänster.
Den delar upp huvuddelarna av RESTful-design i tre steg: resursidentifiering ( URI ), HTTP-verb och hypermediakontroller (t.ex. hyperlänkar ).
RMM har citerats användbar för att utvärdera kvaliteten på särskilt RESTful webb-API-design (även om den inte är begränsad till enbart REST) och kritiserats för att inte ta upp hur ett system skulle kunna uppnå modellens högsta mognadsnivåer samt för att överväga en begränsat antal kvalitetsattribut.
Översikt
RMM kan användas för att bestämma hur väl en webbtjänstarkitektur följer REST-principerna. Den kategoriserar ett webb-API i fyra nivåer (från 0 till 3) där varje högre nivå motsvarar en mer fullständig efterlevnad av REST-design. Nästa nivå innehåller också alla egenskaper hos den föregående.
Andra klassificeringssystem för design av webb-API-tjänster finns också, såsom CoHA och WS 3 .
Strukturera
Nivåer
Nivå 0: The Swamp of POX
Den lägsta nivån i modellen beskriver ett webb-API med en enda URI (vanligtvis POST över HTTP) som accepterar alla de operationer som stöds av tjänsten. Resurser i denna form kan inte definieras väl. Meddelanden sker i XML, JSON eller andra textformat. Dessa är typiska RPC POX och många SOAP- tjänster.
Level Zero-system klassificeras inte som RESTful .
| URI | HTTP-verb | Operationer |
|---|---|---|
| /bokningstjänst | POSTA | hämta destinationer/hotell/rum; lägga till/avboka en reservation; etc. |
| /newsFeedService | POSTA | få alla nyheter; få alla nyheter i kategori specificerade; få alla nyheter om ett specificerat uttag; etc. |
Nivå 1: Resurser
Introducerar resurser och gör det möjligt att göra förfrågningar till individuella URI:er (fortfarande alla vanligtvis POST) för separata åtgärder istället för att exponera en universell slutpunkt (API). API-resurserna är fortfarande generaliserade men det är möjligt att identifiera omfattningen av var och en.
Level One-designen är inte RESTful, men den organiserar API:et i riktning mot att bli en.
| URI | HTTP-verb | Drift |
|---|---|---|
| /bokningDestinationer | POSTA | hämta destinationer |
| /bokning Bokningar | POSTA | lägga till/avboka bokningar |
| /bokningRum | POSTA | lägga till/avboka särskilda önskemål till en bokning |
| /bokningFeedback | POSTA | lämna feedback |
Nivå 2: HTTP-verb
Systemet börjar använda HTTP-verb . Detta gör det möjligt att ytterligare specialisera resursen och därmed begränsa funktionaliteten för varje enskild verksamhet med tjänsten. Principseparationen på denna nivå består i att dela upp en given resurs i två - en begäran om att endast erhålla data (GET), den andra för att modifiera data (POST). Ytterligare granularisering är också möjlig. GET-förfrågningar hämtar endast data, POST/PUT-anrop introducerar ny och uppdaterar befintlig data, DELETE-förfrågningar tar bort eller ogiltigförklarar på annat sätt tidigare åtgärder. En nackdel med att tillhandahålla en distribuerad tjänst med mer än GET och POST per resurs kan vara den växande komplikationen av att använda ett sådant system.
| URI | HTTP-verb | Drift |
|---|---|---|
| /destinationer | SKAFFA SIG | hämta destinationer |
| /reservationer | SKAFFA SIG | få reservationer enligt vissa kriterier |
| /reservationer | POSTA | lägga till/avboka bokningar |
| /rum | POSTA | begära extra rum |
| /rum | RADERA | ta bort extra rum |
Nivå 3 : Hypermediakontroller
Den sista nivån introducerar hypermediarepresentationen. Kallas även HATEOAS (Hypermedia As The Engine of Application State), dessa är element inbäddade i resursernas svarsmeddelanden som gör det möjligt att upprätta en relation mellan individuella dataenheter som returneras från och skickas till API:erna. Till exempel kan en GET-förfrågan till ett hotellbokningssystem returnera ett antal tillgängliga rum tillsammans med hypermedialänkar (dessa skulle vara html-hyperlänkkontroller i modellens tidiga dagar) vilket gör det möjligt att boka specifika rum.
Detta är den sista nivån i Richardson Maturity Model.
Begäran:
GET /room/?customerId=1&date=10-11-2020&hotelCode=ASTORIA HTTP/1.1
Svar:
{ customerId: "1", reservationer: [{rum: "102", checkin: "10-11-2020", utcheckning: "11-14-2020", pris: "100", href: "https:// localhost:8080/room/102"}] }