API’er og socialisme

Illustration: Privatfoto

Jeg er blevet overtalt til at holde et foredrag på tirsdag (1. april, og jeg håber ikke, at der er nogen, der har lavet en udvidet aprilsnar på mig) som en del af Nordic API Tour’en, der sætter fokus på at få mest mulig værdi ud af private og offentlige API’er.

Men da jeg gik i gang med at forberede mig, havde jeg egentlig mange flere spørgsmål, jeg havde lyst til at få besvaret, end fikse og færdige svar, så derfor kom foredraget til at hedde “Who cares about APIs?” og det må jeg jo så hellere forsøge at svare på.

Første svar, der springer i øjenene er: For få. Ja, det er flot, at Programmableweb nu har samlet 10.000 API’er i deres directory, men når der pt. findes 1,8 milliarder websider, så er det jo mildest talt ikke imponerende. Det er jo en enorm skævhed. Webbet er dybest set stadig ikke programmébart med nogle få flashy undtagelser (Facebook, LinkedIn m.fl.) Selv nogle af dem i det virkeligt fine selskab får fra tid til anden sendt signaler til udviklermiljøet om, at det kan være farligt at basere sin fremtid på data eller funktionalitet fra API’erne, hvis man får lavet noget, der virker mere konkurrencedygtigt end “moderapplikationen”.

Jeg sad af andre årsager og kiggede på usability maturity models for organisationer, bl.a. har usability-guruen Jakob Nielsens udviklet en 8-trins model, hvor det ultimative ottende skridt er User-Driven Corporation (var der nogen der sagde Økonomisk Demokrati?) hvor brugerne bestemmer, hvilke projekter, der får tilført ressourcer. Man kunne godt se det at stille API’er til rådighed som en måde netop at skabe dette user-drevne nirvarna, men med en lidt mere liberal vinkel, nemlig at brugerne bidrager med deres egne ressourcer til udviklingen af et økosystem, der rækker ud over virksomhedens grænser.

Eric Raymonds bog “The Cathedral and the Bazaar” fra 1999, der handler om open source og ikke mindst forretningsmodeller indenfor den verden, nævnte som et af punkterne i “bazaar”-modellen (open source): “Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging.” Hvad angår egentlig forretningsmodeller var det dog efter min mening lidt tyndt med i bogen; der tales om en gave-kultur, hvor gevinsten er det ry / brand, man opnår, og princippet “give away the recipe, open a restaurant”, altså at leve af services rundt om den åbne kerne.

Det er på en måde lidt det, et API er; lidt som en opskrift, alle kan bruge (også selvom der kan være grænser for, hvor mange burgers man må lave gratis), og i tilfældet Facebook / Twitter / LinkedIn er app’en restauranten, som trækker kunder til. Men udfordringen opstår, når udviklercommunity’et er så stærkt, at de er i stand til at lave en bedre restaurant end dem, der fandt på opskriften. Er der så stadig et stærkt nok incitament til at stille data og funktionalitet til rådighed via et API?

Og bliver en “API First”-strategi en dag en del af standardpakken af god softwareudvikling, eller må den nøjes med at være for hippe skoledrenge m/k og CEOs der prøver at prakke dig et nyt værktøj på?

P.S. Der er i øvrigt så vidt vides gratis billetter tilbage til de første par kvinder, der ikke er kede af at blive kvoteret til en gratis eftermiddag om API’er.

Kommentarer (8)
Allan Ebdrup Blogger

Jeg er ikke helt sikker på at jeg forstår dit ærinde med dit blogindlæg. Men API'er er en stor del af min udvikler-hverdag, hvor jeg tager S/P/I-aaS produkter ned fra hylderne og strikker dem sammen til et større hele.
Men jeg vil nok være fortaler for et pragmatisk syn på API'er - hvis en stor nok del af dine brugere efterspørger/forventer et API - så giv dem et.

En meget stor del af det jeg laver er API'et i vores produkt. Et API giver mening. Både for at servicere vores webklient, vores smartphone apps og vores partnere.

API'et var tænkt ind helt fra starten af udviklingen, og er (næsten) eneste grænseflade til omverdenen for vores applikation. Men det er ikke API-first, for det, at have mindst to klienter (web og smartphone), der bruger API'et noget tid inden det gøres public, har været guld værd.

API-first, hvor API'et laves (og publiceres) inden klienten der skal bruge det, lyder lidt som en vandfaldsmodel/design-up-front for API-udvikling. Jeg ville nok foretrække et par hurtige iterationer med egne klienter på, inden det publiceres. Men det er måske mig der overser noget her?

Henrik Pedersen

I en eller anden forstand, ja. Det burde de måske.

Kom med et eksempel på et produkt som ikke en eller anden dag kunne stå og mangle en funktion som en anden udvikler gerne vil lave.

Jeg ser personligt et API som en form for "udvidet O" i SOLID.. "Open for extension / closed for modification". Har dit produkt ikke en funktionalitet jeg mangler, så kan jeg selv bygge den, uden at "hacke" (ændre) dit produkt.

Michael Zedeler

For få. Ja, det er flot, at Programmableweb nu har samlet 10.000 API’er i deres directory, men når der pt. findes 1,8 milliarder websider, så er det jo mildest talt ikke imponerende. Det er jo en enorm skævhed. Webbet er dybest set stadig ikke programmébart med nogle få flashy undtagelser (Facebook, LinkedIn m.fl.) [...]

Det passer ikke at de 1,8 milliarder websider ikke har et API - det har de skam. Det hedder HTTP og fungerer glimrende. Denne diskussion kunne være interessant at tage, men det er nødvendigt at grave et spadestik dybere. Det springende punkt er, at alle de funktioner som er til rådighed på nettet er meget svære at få maskinel adgang til (det er lige netop det, man så kan bruge Kapow til). World wide web er stadig et stykke ad vejen fanget i det, jeg ville kalde "syntax hell". Der er en pokkers masse syntaks og meget lidt information i almindelige websider i dag.

Hvis man så endelig går videre og diskuterer hvordan man ad maskinel vej kan få nemmere adgang til alt det, der er på nettet, synes jeg igen at der bliver sprunget til nogle hurtige konklusioner. Ja - man kunne godt ønske sig nogle API'er og bevares - de kunne endda leve ovenpå HTTP, men jeg synes igen at der er nogle meget væsentlige strømninger som er blevet udeladt, nemlig (a) at der er en bevægelse imod "single page applications" som benytter REST og (b) at w3c har en håndfuld standarder der har til mål at indlejre meget mere maskinaflæsbar information direkte i websider (disse standarder lever under samlebetegnelsen "Semantic Web").

Jeg tror i virkeligheden at det største problem vi kan få fremover, er for mange API'er. Vi kan måske have teoretisk adgang til hundredetusindevis af systemer, men hvis de alle har forskellige API'er, er det håbløst at bruge særligt mange af dem på en gang. Det er simpelt hen for krævende at tage i brug.

Det interessante problem er imho ikke at få API'er på alting, men at få standardiserede API'er, som kan bruges på tværs af de forskellige systemer, der findes.

Det kan ske igennem officielle standarder fra organer som w3c (f. eks. OWL, SPARQL og SOAP) eller igennem defacto standarder (f. eks. REST).

Anne-Sofie Nielsen Blogger

Det interessante problem er imho ikke at få API'er på alting, men at få standardiserede API'er, som kan bruges på tværs af de forskellige systemer, der findes.

Der er ingen tvivl om, at et API ikke bare er et API. Der kan f.eks. være enorm forskel på, hvor brugervenligt det er, hvor god dokumentationen er osv. Og hvis man tror, at OAuth er en standard, der betyder, at man kan genbruge sin kode til at authenticate mod Facebook til også at authenticate mod LinkedIn og Twitter, så bliver man slemt skuffet.

Anne-Sofie Nielsen Blogger

Kom med et eksempel på et produkt som ikke en eller anden dag kunne stå og mangle en funktion som en anden udvikler gerne vil lave.

Spørgsmålet er dog, om man kan forudsige behovene tilstrækkeligt på forhånd til at lave en API, der også dækker fremtidige behov? I den objektorienterede verden har jeg ofte set folk lave fine abstraktioner over et enkelt eksempel, som så reelt viser sig ikke at have abstraheret over de relevante aspekter, når eksempel nummer to dukker op.

Det er ikke nødvendigvis nemt at lave et godt API, som dækker en bred vifte af anvendelser. Og derfor bliver det så også vigtigt, at man tænker over f.eks. versionering, så man kan have flere versioner af API'et kørende uden at trække tæppet alt for hurtigt væk under applikationer, som bruger en tidlig version.

Henrik Pedersen

Det er et helt andet problem at lave gode API'er. Jeg kan ikke vide hvor meget hardware hacking du har lavet gennem tiden, men rent personligt så er jeg god damn træt af internet-tilkoblede produkter uden API'er. Selv et elendigt uversionieret API som kun tilbyder 75% af funktionaliteten er bedre end ingenting set i min optik.

For min skyld kunne det være en tjekboks i indstillingerne der slår muligheden for at lave HTTP Basic authentikerede GET requests til..

Den mest frustrerende følelse jeg kender i hele verden er at stå med et produkt (fysisk eller virtuelt) hvor man har en god idé man godt lige ville prøve af, men ikke har muligheden for at gøre det fordi eksisterende grænseflader er hemmelige eller fordi der simpelthen mangler god API adgang. Så er det at man som udvikler falder tilbage på reverse engineering eller decideret screen-scraping (hvis det er en hjemmeside).

Et konkret eksempel fra den fysiske verden er TDC's alarmbokse. De har IP adresser og et eller andet kontrolpanel, men man må ikke få koderne oplyst og ej heller tilgå noget API hos TDC, trods de selv kan fjernstyre dem fra hjemmesiden. Det var en opgave hos min fætter hvor jeg ville have udvidet et egenudviklet overvågningssystem med apps til telefonen med muligheden for at slå alarmen til og fra, og evt. at optage med kortere intervaller hvis alarmen blev aktiveret.
Bare et super simpelt REST API som kunne aktiveres selektivt ville have været perfekt. Dette (og så generel elendig service) fik ham til at gå væk fra TDC igen. Jeg har mange andre historier fra hardware verdenen med alt fra ringeklokker til digitale badevægte.

Jeg synes det er dybt irriterende at der er hemmelighedskræmmeri omkring ALT nu til dags. Jeg kan godt forstå man ikke vil investere millioner i API'er, men ofte ville helt basale papirer fra ens ingeniører med nogle hints omkring protokoller eller anden teknisk implementering være mere end nok. De kinesiske virksomheder som ønsker at plagiere skal nok gøre det alligevel, så det giver ikke nogen mening at hemmeligholde sådanne informationer. Og hvem ved, måske er der en flok brugere som danner et miljø omkring dit produkt som du aldrig havde forudset?

Kjeld Romer Larsen

Hvis svaret er API hvad er så spørgsmålet. Når man sidder med en lang række programmer som hver for sig løser en opgave men som i den grad savner at tale sammen med andre så bliver API'er en vigtig del af at kunne yde den bedste service.
Mange steder giver manglende API'er grobund for genindtastninger eller udvikling af dyre integrationer, som skal vedligeholdes af specialister. Det giver en dyr drift. Hvis API'er skal give mening så skal de efter min opfattelse basere sig på standarder, som kan give den enkelte kunde mulighed for at vælge mellem mange forskellige 3. parts leverandører.

Log ind eller Opret konto for at kommentere