Tillbaka till framtiden med REST
Vad är det för skillnad mellan en REST-tjänst och en "vanlig" Webbtjänst?
Är REST bättre än SOAP?
Hur gör vi för att använda det i våra system?
Diskussionen kring REST, eller Representational State Transfer, har på senare tid blommat upp rejält och jag möts lite nu och då av frågorna ovan. Träffar jag istället någon som är mer påläst på området möts jag ofta av en stor entusiasm och övertygelse. Lite som om personen ifråga har sett “ljuset”. Det är så vackert... Min uppfattning är att det finns två grupper av REST-anhängare; de som är övertygade och de som är nyfikna. Denna artikel vänder sig främst till er som är nyfikna.
I dag säger man vanligtvist Webbtjänster om tjänster som utbyter SOAP meddelanden över HTTP. Är det verkligen korrekt? På flera sätt följer inte SOAP Webbens arkitektur alls. Det finns som nämnt bindningar för att kommunicera med SOAP över HTTP men många aspekter av SOAP motsäger sig Webbens tillståndslösa natur. REST å andra sidan nyttjar HTTP:s semantik vilket gör det väldigt tillgängligt och enkelt att komma igång med. Har plattformen en HTTP stack så kan du kommunicera med ,och exponera, REST-tjänster. Detta tror jag är nyckeln till RESTs framgång hittills. Med utökat verktygsstöd samt introduktionen av erbjudanden som t ex Azure, vars gränssnitt exponeras till stor del av REST-tjänster, tror jag att vi bara har sett början av REST-vågen.
Den största skillnaden mellan en sk RESTful tjänst och en SOAP/HTTP Webbtjänst är att REST-tjänsten exponerar kollektioner av Resurser medan SOAP/HTTP-tjänster exponerar metoder. Varje REST Resurs identifieras av en unik URL och implementerar ett antal standard operationer som tillåter konsumenten att skapa, läsa, uppdatera och radera resurser (CRUD). Dessa operationer representeras av standard HTTP verb som GET, POST, PUT och DELETE. Vissa tjänster passar naturligt in i REST-modellen - ofta när Resursen är tydligt identifierad och tjänsten mest handlar om att hantera denna resurs.
Kunder vill ofta höra våra sk Best Practices kring mönster och teknikval. REST är inget undantag. På vilket sätt skall vi bygga våra RESTfulla tjänster på er platform?
Mitt första inlägg jag skrev här på bloggen heter "WCF Best Practices". Även om jag använde uttrycket Best Practices där så vill jag poängtera att det sällan finns ett gyllene sätt att lösa flera problem med. Det gyllene sättet (Best Practice) måste sättas i sitt sammanhang vilket med största sannolikhet resulterar i olika lösningar för olika sammanhang.
Jag har nedan sammanställt Microsofts REST-landskap som jag ser det. Till varje erbjudande har jag skrivit en kortare kommentar så du själv kanske kan identifiera vad som kan innehålla rätt lösning för dig.
Med WCF 3.5 fick vi på riktigt stöd i WCF för att bygga REST-tjänster. WebHttp bindningen är utgångspunkten. Använd detta om du är bekväm med WCF. WCF REST Starter Kit innehåller klasser och Visual Studio tillägg som gör det enklare för dig att utveckla WCF REST-tjänster i synnerhet och konsumera REST-tjänster i allmänhet.
ADO.NET Data Services är en del av ADO familjen och är baserat på WCF. Används med fördel till att exponera datamodeller som AtomPub tjänster. Introducerar en del ramar som hjälper dig att snabba upp utvecklingen. Bygger du en Silverlight applikation eller tittar på Azure Services Platform är detta ett hett alternativ.
ASP.NET MVC är kanske tom det RESTfulligaste erbjudandet. Bygger du en MVC applikation och vill exponera REST-tjänster för att driva viss funktionalitet kan detta med fördel göras i passande Controller. En vy av din information behöver inte vara något som skall presenteras för en människa. Vyn kan lika gärna bestå av t ex XML eller JSON ämnat för konsumtion av en applikation.
Introducera inte WCF i mixen om det inte är absolut nödvändigt.
ASP.NET HttpHandler; Är du bekväm med ASP.NET, bygger inte en MVC applikation, och anser att det tar för lång tid att läsa in dig på WCF. Då kan en HttpHandler absolut vara rätt verktyg för jobbet. Här har du dock minst infrastruktur att ta hjälp av, vilket kommer resultera i att du skriver mer infrastrukturrelaterad kod i dina tjänster.
Hur kan något så relativt "gammalt" plötsligt kännas som framtiden? Håll det simpelt säger jag bara.