Web-omfavnendene services services og åbne API’er

En ny måned et nyt webframework fristes man næsten til at sige, hvis man færdes blandt udviklere påtwitter og i andre sociale medier i disse dage. Traditionen tro sker der indimellem det at et teknisk område for fokus, og så opstår der et væld af frameworks og en masse debat præget af subjektive holdninger omkring hvilket der er bedst. Personligt tror jeg det er sundt nok, da det er en måde at få diskuteret design på, selvom der til tider er mere støj end konstruktiv diskussion.

Image

For tiden er et af de hotte emner http baserede services, hvor der primært er tre frameworks i spil – NancyWebAPI og ServiceStack.  Nancy og ServiceStack open source, og WebAPI eropen source software og udviklet af Microsoft.

Der er to overordnede scenarier hvor sådan nogle frameworks er interessante i forhold til de produkter vi i sidste ende udvikler. Det ene scenarie hvor vi bruger dem er til kommunikation imellem adskilte dele internt i et system – typisk rige klienter i Silverlight eller Javascript. Det andet scenarie er for at udstille et API, sådan at andre applikationer kan læse eller opdatere data – typisk til brug fra mobile applikationer på telefoner og tablets. Begge scenarier er højaktuelle, fordi der er så meget fokus på HTML5 og mobile apps.

Om en måneds tid d. 25/4 er jeg med til at lave en lightning talk i vores lokale .NET brugergruppeANUG omkring emnet, hvor vi er tre udviklere der hver præsenterer et af de førnævnte frameworks. Så med afsæt i det tænker jeg at det er oplagt at skrive lidt mere overordnet om emnet, hvorfor det er interessant for os udviklere og i sidste ende interessant for vores kunder.

RESTafarian eller RESTless – gradbøjning af HTTP baseret arkitektur

REST som er et akronym for representational state transfer, er en arkitekturel måde at opbygge sine hypermedia services. Meget forenklet går det ud på at man udnytter http protokollen, sådan at eksempelvis verber bruges til at angive om der et tale om en operation der læser, opretter, opdaterer eller sletter fra en ressource.

Hvorvidt og i hvilket omfang det er en god ide at lave REST services er en religiøs diskussion, så den vil jeg prøve at holde mig ude af. Uden at støde nogen tror jeg at jeg kan sige at overholdelse af REST principperne potentielt kan give den fordel at man har en velkendt protokol, som nogen klient frameworks forstår at kommunikere med. Omvendt introducerer man også noget teknisk kompleksitet som kan have udfordringer, da ikke alle verber understøttes direkte af browsere og  udviklere der benytter ens API skal forholde sig til det.

De tre frameworks Nancy, WebAPI og ServiceStack er grundlæggende meget ens idet de giver mulighed for at lave REST services, men man er også fri til at være RESTless – som er en anden måde at sige at man bruger http og adopterer et eller andet subset af reglerne fra REST efter behov og kokkens humør. Der er forskelle i helt hvor tæt forskellige frameworks følger REST, men de er rimeligt subtile i sidste ende, så krav til REST diskvalificerer ikke nogen af dem.

Intern kommunikation – subsystemer og rige klienter

Kommunikation internt i et system imellem subsystemer og rige klient er naturligvis ikke noget nyt som sådan. Det nye er omfanget af rige klienter på web, fordi der er kommet fokus på den lækre brugsoplevelse, og websites der minder i opførsel om native mobile apps. Jo mere funktionalitet der ligger på klienten, jo større er behovet for at kommunikere frem og tilbage. Det gælder både imellem server og klient for at få data persisteret og imellem udviklere der har hvert sig ansvarsområde. I direkte forlængelse af dette skrives der mere service kode, og behovet for at skrive tests bliver større.

Her begynder vi at se nogle af de områder hvor der er forskel på Nancy, WebAPI og ServiceStack.

Nancy er bygget med testbarhed som et fokusområde, så der følger nogle værktøjer ogeksempler med på hvordan man med få linier kode kan skrive en test der kalder ens service og validerer det svar man får tilbage. Her har Nancy en bedre historie end konkurrenterne og er med til at gøre arbejdet lettere.

ServiceStack har tilgengæld en unik feature ved at det automatisk udstiller websider der tjener som dokumentation for ens services. Hvis man arbejder på et team hvor det er forskellige udviklere der arbejder på serveren og klienten kan det gøre livet lettere, da man kan spare noget dokumentation og koordinering.

WebAPI har ligeledes en speciel feature, ved at man kan udstille data som forbrugeren af servicen kan bede om at få behandlet ved at angive nogle kriterier i url’en. Det betyder at klienten kan styre pageing, sortering og filtrering uden at der skal implementeres specifikke metoder til hvert scenarie.

Eksempelvis kan man lave pageing af brugere sorteret på navn hvis man har en ressource på adressen http://www.mysite.com/api/users ved at tilføje et filter sådan at man springer 20 elementer over og henter de næste 10 således:

http://www.mysite.com/api/users?$skip=20&$top=10$orderby=Name

Eksterne API’er og den vide verden

Virksomheder som facebook, google og twitter gør meget ud af at have eksterne API’er, sådan at man kan interagere med dem på andre måder end ved at være logget ind på websitet ved hjælp af browser. Ved at udstille sådan nogle API’er har de været med til at gøre mange andre websites bedre – tænk bare på Spotify hvor man får en social oplevelse omkring det musik man hører og alle de sites der har google maps visninger til at hjælpe dig med at finde vej.

Eksterne API’er er dermed grundlaget for en interessant videreudvikling af internettet, som både API’ernes udbydere og forbrugere drager nytte af sammen med deres kunder.

Jeg tror og håber at andre og mere almindelige virksomheder vil følge efter, og tænke over hvordan de kan udbyde oplysninger om deres kompetencer, services og produkter. Faktisk har vi hos Vertica implementere et API for trollbeads, som har set værdien i at udstille et API sådan at det kan udvikles mobile apps der gør brug af de data de allerede har.

I forhold til udvikling af sådan nogle API’er er det igen relevant at se på de styrker Nancy, WebAPI og ServiceStack har.

Som nævnt har Nancy gode faciliteter til at skrive tests. Det er om noget endnu mere vigtigt i forhold til et eksternt API, hvor eventuelle fejl hurtigere får større konsekvenser, og hvor et brud på API’et saver benene væk under forbrugerne af API’et.

ServiceStack understøtter ud af kassen det største antal data formater, hvor man som nævnt automatisk for dokumentation stillet til rådighed. XML og JSON som er de mest anvendte understøttes af alle tre frameworks, men understøttelse af SOAP kan være en fordel for nogle klienter. Iøvrigt har service stack mest fokus på performance med store mængder data af de tre.

Muligheden for at klienten kan efterspørge filtrering af data med WebAPI betyder at man nemt kan lave et mere fleksibelt API. Det er en stærk feature, men som bekendt er der “no such thing as a free dinner”. Ulempen er at man som udbyder ikke i samme grad kan optimere den underlæggende database, fordi man ikke ved præcis hvordan data ender med at blive filtreret og sorteret.

Takeaways

Valg af et service framework er som udgangspunkt en teknisk bekymring, og det er i høj grad et område hvor man kan tale om smag og behag hos den enkelte udvikler. Hvilket service framework man vælger kan imidlertid vise sig væsentlig for slutproduktet.

Der er objektivt set ikke noget “rigtigt valg”, men det er relevant at afklare hvilke design kriterier der har højest prioritet – både for at få det meste ud af udviklingstiden og for at kunne drage fordel af de styrker de enkelte frameworks har. På den måde et det et godt eksempel på et af de områder hvor det er vigtigt at teknisk forståelse og domæneviden mødes for at man kommer frem til den bedst mulige løsning.

Det er næsten kun fantasien der sætter grænser for hvad den enkelte virksomheds data kan bruges til, hvis man giver andre virksomheder med andre kompetencer mulighed for at samarbejde. Det er helt klart nødvendigt at tænke over ikke at afsløre vigtige forretningshemmeligheder – men der er spændende muligheder i at være mere åbne og overveje hvad man egentlig behøver holde hemmeligt.

Christian Holm Nielsen 
Vertica A/S

Kategorier: Forretning, Mobil, Udvikling

Tagged as: , , , ,

Skriv et svar

Udfyld dine oplysninger nedenfor eller klik på et ikon for at logge ind:

WordPress.com Logo

Du kommenterer med din WordPress.com konto. Log Out / Skift )

Twitter picture

Du kommenterer med din Twitter konto. Log Out / Skift )

Facebook photo

Du kommenterer med din Facebook konto. Log Out / Skift )

Google+ photo

Du kommenterer med din Google+ konto. Log Out / Skift )

Connecting to %s