Tillbaka till framtiden med REST

  • Artykuł

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.

rest-landscape

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.

Mer information kring REST och .NET

Comments

  • Anonymous
    August 14, 2009
    Bra översikt över våra olika tekniker för REST-baserade tjänster!Jag skulle vilja lägga till att användandet av SOAP i tjänsteorienterade scenarion ofta handlar om meddelandebaserad kommunikation och integrationsscenarion. Där finns det fortfarande goda skäl att dra nytta av olika teknik-stackars mogna stöd för SOAP och WS*-standarderna med stöd för Contract First, meddelandebaserad säkerhet, transaktioner, routing mellan flera tjänster osv. – något som kan vara en utmaning att bygga motsvarande stöd för i en rent REST-baserad arkitektur.Som allt annat gäller ju att har du sett ljuset är ju risken att allt börjar likna spikar som bör hamras i med REST-hammaren :-)
  • Anonymous
    August 16, 2009
    Tack för din kommentar Robert!Jag håller med dig helt och hållet.Då en av frågeställningarna i introt var "är REST bättre en SOAP" så borde en förklaring i stil med din absolut varit på sin plats. (Det skulle kanske tom krävas en separat blogpost för att reda ut frågeställningen?)Min avsikt med denna bloggpost var primärt att kartlägga vårt REST-teknik-landskap.REST är i min mening ytterligare ett verktyg att placera i snickarbältet och skall, som allt annat, användas efter omtanke.