Att välja mellan .Net Web Services och Web API

Ett vanligt problem som jag stöter på i min arbetsvardag i IT-branschen är när det kommer till val utav metod för att exponera gränssnitt mot de tjänster man utvecklat eller implementerat.

Jag tänkte därför att jag skulle ge mig på att kort försöka redogöra för två utav de vanligare metoderna inom .Net-ramverket, Web Services och WebAPI, samt vilka för- respektive nackdelar de har.


Web Services

I enterprise-sammanhang har det under en längre tid varit väldigt populärt att använda sig utav (SOAP) web services. En bidragande faktor till dess omåttliga popularitet är troligen det faktum att du förväntas publicera en definition av servicen som en del utav varje implementation (en sk. WSDL), vilket gör att servicen i fråga skulle kunna betraktas som självdokumenterade. I miljöer där det rör sig mycket, ex. i form av hög konsultandel eller personalomsättning kan det därför vara intressant att bygga sina integrationspunkter på detta sättet för att se till att inte tappa greppet om förvaltningen.

En annan positiv faktor som bidragit till web services popularitet som integrationsgränssnitt är att de, i och med sin WSDL, möjliggör automatisk detektering och konsumering i klientsidan. Om så önskas kan man till och med automatiskt generera stubbar i sin klientkod utifrån servicens WSDL (Stack Overflow).

All denna komplexitet leder dock till att gränssnitten blir förhållandevis dyra, i dubbel bemärkelse (utvecklingskostnader, overhead). Detta då standarden är beskriven med hög granularitet och i de allra flesta implementationer innehåller funktionalitet som egentligen inte är nödvändig för att kunna realisera det aktuella användningsfallet/kravet (Se W3C: Web Service Activity).

Sammafattningsvis:

  • Kan endast hantera XML
  • Kan inte komprimera informationsinnehållet
  • Kan endast driftas i en IIS.
  • Kan konsumeras av alla klienter som kan hantera XML
  • Kan upptäckas och konsumeras automatiskt i och med definitionen (WSDL).

WebAPI (HTTP/Rest)

webapi

Till skillnad från Web Services så är RESTful services oerhört löst definerade och dess standard skulle förmodligen kunna beskrivas på mindre än två A4-ark. Som någon så fiffigt uttryckte det:

Om WebAPI är en motor, är Web Services en Audi A5 2014.

Det är alltså inte helt enkelt att göra en jämförelse mellan dessa standarder då de inte nödvändigtvis delar tillräckligt många fundamentala egenskaper. Till skillnad från Web Services är WebAPI:er exempelvis fria från restriktioner kring vilka format som skall användas för in- och utdata. Medans Web Services är hänvisade till XML för såväl request som response kan man i ett WebAPI alltså implementera en valfri blandning av json, bson, xml, csv etc.

Den största nackdelen med WebAPIer i relation till Web Services är dock dess avsaknad av publika tjänstedefinitioner. Det är alltså inte möjligt att vare sig detektera eller konsumera ett WebAPI automatiskt, utan det krävs istället att gränssnittet dokumenteras noga och därefter implementeras i klientänden. Detta har dock även fördelar, exempelvis då det möjliggör komprimering utav hela det kommunicerade informationsinnehållet, något som inte är möjligt om man skall följa Web Service-standarden då klienten utan vidare komplikationer förväntas kunna nyttja det returnerade innehållet.

Sammanfattningsvis:

  • Byggt med enkelhet och snabbhet i åtanke.
  • Kan generera svar i ett eller flera format ex. json, bson, xml, csv.
  • Kan kombineras med funktionalitet i MVC.Net, ex. Routing och Controllers.
  • Kan driftas både som en fristående tjänst (sk. self-contained WebAPI) och i en IIS.

Vad ska jag välja?

Trots den nästintill hegemoniska ställning Web Services haft inom branschen tycker jag mig känna av en tydlig omställning bland såväl kollegor som ”branschisar” mot att i högre grad nyttja WebAPIer vid gränssnittsutveckling. Detta motiveras ofta med den högre graden flexibilitet och de lägre implementationskostnaderna som dessa medför.

Med detta sagt är det dock inte nödvändigtvis vara så att det inte finns en plats för Web Services i tjänstekartan även i framtiden. I de fall där det inte finns ett tydligt ”kontrakt”  mellan klient och server, ex. vid publik exponering av gränssnitt, finns det fortfarande klara poänger i att använda sig utav web services för att förenkla implementationen för de konsumerande tjänsterna/klienterna.

Innan ett informerat val kan göras kan det dock vara värt att resonera lite extra kring ett antal frågor som kan påverka ditt val av teknisk lösning. Exempel på sådana frågeställningar skulle kunna vara:

  • Vilka är den tänkta målgruppen?
  • Finns behovet av en publik tjänstedefinition?

Skall APIet vara publikt/konsumerbart ifrån flera olika klienter/tjänster eller är det en definerad uppsättning tjänster som skall kunna nyttja det? Om interfacet skall användas publikt kan det finnas poänger i att välja Web Services framför WebAPIer.

  • Vilka utdataformat behöver vi kunna hantera?

Önskas en flexiblitet i dataformat, dvs. möjligheten att hantera såväl JSON som SOAP/XML så kan det finnas klara fördelar i att använda WebAPIer. Om inte annat för att det innebär betydligt lägre komplexitetsgrad i ditt backend.

  • Hur bråttom är det?

Här finns det antagligen lika många skolor som det finns utvecklare. Min personliga erfarenhet säger att det är en betydligt kortare utvecklingscykel vid nyttjande av WebAPI:er än för Web Services, men om resursen som skall genomföra utvecklingen är mer bekväm med någon utav metoderna så kan det såklart finnas vinster i att gå på den linjen.

  • Hur statiskt kommer interfacet vara?

Hög förändlighet ställer också höga krav på dokumentationen. Kommer din organisation att mäkta med att underhålla en sådan dokumentation? Finns det några tvivel kan Web Service vara att föredra i och med den publika tjänstedefinitionen (WSDL).