Microsoft har nyligen släppt ASP.NET Web API som ersättare för WCF Web API för att bl.a. bygga REST-tjänster. Men är det verkligen bättre?
Microsofts WCF Web API har under en tid varit den senaste plattformen för att implementera REST-tjänster genom WCF efter att ha föregåtts av andra tilläggsmoduler så som WCF Rest Starter Kit och WCF WebHTTP. Samtidigt har MVC-teamet levererat moduler för att man ska kunna returnera strukturerad data via controllers. En hel del förvirring har funnits bland utvecklare om vilken teknik man ska välja.
I februari släppte Microsoft MVC 4 beta som bl.a. innefattar ASP.NET Web API som är en sammanslagning av det bästa från MVC 3 och WCF Web API, vilket i sin tur sänder föregående plattformar till graven. I Augusti släppte man ramverket fullt ut.
Nyheter
Det finns många nyheter i ASP.NET Web API och flera underlättar implementation av REST-tjänster.
Full route support
MVC-ramverket introducerade routes för att specificera hur en HTTP-request mappas till en kontroller, detta är nu fullt implementerat i ASP.NET Web API vilket underlättar mappning av REST urler till metoder.
Innehållskännedom
Klient och server kan nu tillsammans bestämma i vilket format innehåll ska skickas som. ASP.NET Web API stödjer idag XML och JSON genom att definiera Accept och Content-type för HTTP.
Modellkopplare
Konvertering av HTTP requests till .NET-objekt är väldigt enkelt och sker mha modellkopplare. Eftersom HTTP är ett protokoll som har ett rikt uppslag av verb, eller metoder om man så vill kalla det, passar det bra ihop med REST-standarden.
HTTP modell
ASP.NET Web API implementerar HTTP request och response-objekt samt ett HTTP klient-objekt för klienter. Detta förenklar manipulation och tolkning av HTTP-kommunikation.
OData Querys
Genom att returnera IQueryable<T> så stöjder Web API querying via OData URL konventioner. Detta förenklar data-manipulation när man t.ex använder en databas. OData baseras för övrigt på AtomPub vilken i sin tur bygger på en REST-arkitektur.
Hjälpsidor och testklient
Precis som i WCF kan man automatisera hjälpsidor och testklienter för att enkelt kunna publicera beskrivningar hur t.ex. en REST-tjänst anropas samt testa sin tjänst.
Fler funktionaliteter
Förutom ovanstående har det tillkommit funktionaliteter som underlättar många andra mer generella delar i utveckling av en REST-applikation.
Filter
ASP.NET Web API stödjer filter som t.ex. Authorize. Filter kan användas för att hantera t.ex. händelser, autentisering och felhantering.
Kodbaserad konfiguration
Ingen mer konfigurering i config-filer, ASP.NET Web API konfigureras helt och hållet i koden via t.ex. attribut och filter.
Egen värd
ASP.NET Web API behöver inte längre hostas av IIS.
Förbättrad IoC (Inversion of Control)
ASP.NET Web API använder MVC’s DependencyResolver för att stödja löst kopplade beroenden mellan komponenter.
Förbättrade testmöjligheter
Enklare att bygga testfall eftersom Web API använder en förbättrad HTTP-modell (HttpRequestMessage ochHttpResponseMessage) utan behov av statiska kontexter.
Det finns många fler förbättringar och nya funktionaliteter som jag inte beskrivit, alla kan hittas på http://www.asp.net/web-api .
Kodexempel
För att visa på en del av skillnaderna mellan WCF Web API och ASP.NET Web API har jag skrivit ihop några enkla kodavsnitt för ett REST-api för ett bibliotek där man vill kunna hämta böcker beroende på ISBN-nummer.
Bok-entiteten kan se ut så här:
namespace Library.Resources
{
public class Book
{
public int ISBN { get; set; }
public string Title { get; set; }
}
}
WCF Web API
I WCF Web API skulle en implementation av API’t kunna se ut så här:
using System.ServiceModel;
namespace Library.API
{
[ServiceContract]
public class LibraryApi
{
[WebGet(UriTemplate = "{isbn}")]
public Book Get(int isbn)
{
var book = new Book()
{
ISBN = isbn, Title = "My Awesome Book"}
};
return book;
}
}
}
I global.asax skulle service-routingen kunna se ut så här:
public static void RegisterRoutes()
{
RouteTable.Routes.Add(
new ServiceRoute(
"api/books",
new HttpServiceHostFactory(),
typeof(LibraryApi)
)
);
}
ASP.NET Web API
I ASP.NET Web API skulle samma implementation kunna se ut som följande:
using System.Net.Http;
namespace Library.API
{
public class LibraryApi : ApiController
{
public Book Get(int isbn)
{
var book = new Book()
{
ISBN = isbn, Title = "My Awesome Book"
};
return book;
}
}
}
I global.asax skulle routingen kunna se ut så här:
public static void RegisterRoutes(RouteCollection routes)
{
routes.IgnoreRoute("{resource}.axd/{*pathInfo}");
routes.MapHttpRoute(
"DefaultApi",
"api/{controller}/{id}",
new { id = RouteParameter.Optional }
);
}
Skillnader syns ganska tydligt i exemplena även om det är väldigt enkla exempel. Routingen t.ex. som numera bygger på MVC’s routing istället för URI templates, service-kontrakt som nu istället bygger på MVC controllers och action-metoder istället för attribut. I artikeln “Your First Web API (C#)”, första avsnittet, “Create a Web API Project”, finns det en mer detaljerad beskrivning hur man går tillväga för att bygga ett API i ASP.NET Web API med tillhörande kod som man kan ladda ner för att experimentera själv.
Sammanfattning
Har man utvecklat en REST-applikation i WCF Web API är det inte nödvändigt att migrera till ASP.NET Web API. WCF Web API har stöd för att bygga REST-applikationer, det är dock lite omständigare än att använda ASP.NET Web API för att åstakomma samma sak.
Bygger man en REST-applikationer från start är valet givet; ASP.NET Web API är vägen att gå. Routing-delen är mycket mer välutvecklad och är betydligt mer översiktsvänlig. CRUD-operationer är snyggt och färdigt packeterat från början, och det behövs inga krångliga konfigurationer för att få en tjänst att fungera.
Det ska vara enkelt att sätta upp en tjänst, och det ska gå fort, och det tycker jag Microsoft har lyckats med den här gången.