API’er er (stadig) ikke til at stole på
Historien har det med at gentage sig, og fører nogle gange til, at man som blogger får en utrolig lyst til at smække en genudsendelse af et af sine tidligere indlæg på. Jeg skrev for bare et halvt år siden en advarsel mod at tro, at man trygt kan basere sine applikationer på eksterne API’er, dengang foranlediget af, at Twitter havde ændret sine betingelser for hvilke typer af klienter, man måtte bygge ovenpå deres API.
Nu er det så Facebook, der har været ude at kvæle en spændende ny applikation, Wander, der tilbød forskellige former for lokationsbaseret søgning indenfor brugerens netværk (eks. caféer i nærheden, som brugerens venner havde besøgt). 3 timer i luften fik Wander før Facebook lukkede for Wanders brug af Facebook-API’et. Farvel og tak til de 100-vis eller 1000-vis af udviklingstimer, som Wanders skabere må have lagt i den. Vi må da håbe, at de har en plan B.
For nyligt opdagede jeg også, at LinkedIn sidste år lukkede for, at man i søgninger fra API’et kunne få resultater indeholdende personer, der var længere ude en 1. eller 2.-grads kontakter i netværket - endnu et eksempel på, at API’et tilbyder en ringere funktionalitet end på LinkedIns eget website.
Virksomhederne lukker sig i stigende grad om dem selv og deres data. Så hvis ikke man er blandt de applikationer, der tilføjer yderligere værdi til API’ernes udbydere (i form af at tilføje yderligere connections, statusopdateringer mm.) men kun forbruger deres data, ville jeg være stærkt bekymret for deres incitament til at holde linjen åben.
Lidt lyspunkter er der dog stadig; eksempelvis initiativet Common Crawl, der crawler webdata og stiller dem åbent tilgængelige for at andre kan trække interessant værdi ud af de store mængder tekst og metadata, de efterhånden har samlet. Her håber man ikke at blive uvenner med hjemmesidernes rette ejermænd ved at overholde eventuelle begrænsninger i robots.txt. Spørgsmålet er dog, om det er tilstrækkeligt - der kan godt være forskel på en sides interesse i at blive gjort tilgængelig via en søgemaskine versus at aflevere en kopi af hele sit indhold til uspecificeret processering af tredjeparter.
Om Anne-Sofie NielsenAnne-Sofie Nielsen er udviklingschef hos Kapow Software og har en baggrund som civilingeniør i informatik fra DTU. Har aldrig helt fået besluttet sig for at være en nørd eller ej.
Follow @femalenerdKommentarer (13)
heller ikke forretningsmæssigt. Man har vel API fordi man har en forhåbning om at en tredjepart vil udvikle en smart lille applikation, som kan give værdi tilbage til tjenesten - enten i form af mere trafik, nye anvendelsesmuligheder eller data. Så medmindre man er inde og pille ved noget, der ikke var hensigten, så er det ikke en særlig smart strategi mht. API'er.
Hvis man én gang har spildt 100+ udviklingstimer på en tjeneste, som så trækker stikket i værdikæden, så vender man vel næppe tilbage - og det rygtes jo. Der skal mindre til. Da gMaps smed restriktioner og pris på deres, var der mange udviklere der flytte til fx cloudmade.
-
9 -
0
Helt enig Jesper.
Nu er både Facebook, Twitter o.a. kommercielle aktører heller ikke det bedste eksempel. Det interessante er, at den danske stats satsning på frigivelsen af offentlige data kan ramme den samme problematik. En del af det potentiale som EU og andre antager, at der er i åbne data, skal realiseres gennem nye services, forretninger og applikationer. Det må antages at den datafordeler som er i udbud også skal have en form for webservice/API adgang. Med andre ord begynder API'er at indgå som en del af værdikæden i flere og flere services. Det kræver igen en rigtig god fornemmelse for hvilken ToS der skal indgå, hvordan man varsler ændringer i datasæt og for alt i verden ikke trække stikket for en flok udviklere. Hvis dette led i værdikæden forbliver usikkert, så kan potentialet aldrig realiseres.
Jeg har personligt svært ved at se hvordan det skal kunne lade sig gøre p.t., men det vil være en problematik, som bliver aktuel hvis staten forventer at udviklere vil forsøge at skabe en forretning på eksempelvis åbne data. Jeg synes at det er ret interessant at holde øje med hvad der sker med kommercielle services og API'er, som et udgangspunkt for at forstå det ansvar myndighederne har omkring åbne data - både i forhold til det tekniske og ToS/værdikæde.
-
4
-
0
Jeg har personligt svært ved at se hvordan det skal kunne lade sig gøre p.t.
Versionering af endpoints/services?
Selvfølgelig kan der komme problemer, hvor man er nødt til at lave en "breaking change" til et API, men min egen erfaring på det kommercielle marked er, at langt de fleste udvidelser og ændringer kan håndteres med en korrekt strategi for hvordan endpoints/contracts (i WS-forstand) versioneres og udstilles.
Det er sjældent raketvidenskab - selv ikke hvis det overordnede mål er en ubetinget "sømløs" oplevelse for eksisterende brugere af et API.
-
2
-
0
Ligesom det heller ikke er en særlig smart strategi at basere ens forretning på gratis anvendelse af et API til en service, der koster mange penge at drive.
Måske ikke, men i de nævnte services er der som udgangspunkt ikke mulighed for at betale sig for en større sikkerhed for, at ens applikation eller de dele af API'et som den bruger, ikke pludselig bliver lukket.
-
0
-
0
Måske ikke, men i de nævnte services er der som udgangspunkt ikke mulighed for at betale sig for en større sikkerhed for, at ens applikation eller de dele af API'et som den bruger, ikke pludselig bliver lukket.
Og? Det er jo en risiko man så løber som virksomhed - ganske ligesom alle mulige andre risici man bør overveje og håndtere løbende.
Nothing to see here - please carry on ... :o)
-
2
-
2
@Jesper Lund Stocholm
Og? Det er jo en risiko man så løber som virksomhed - ganske ligesom alle mulige andre risici man bør overveje og håndtere løbende. Nothing to see here - please carry on ... :o)
Reductio ad absurdum.
Hvis du er grundlæggende uenig i, at det er forkert at lukke for f.eks. Wander efter 3 timer, så skriv det. Det andet er bare en kæmpe floskel.
-
1
-
1
Hvis du er grundlæggende uenig i, at det er forkert at lukke for f.eks. Wander efter 3 timer, så skriv det. Det andet er bare en kæmpe floskel.
Jeg er overhovedet ikke enig i, at det er et problem at der blev lukket for Wonder (jeg kan naturligvis godt isoleret se problemet fra Wanders side). Jeg er fuldt af den overbevisning, at det er fuldstændigt idiotisk at basere sin forretning på et API, hvor der ikke er en gensidigt forpligtende aftale om brug, SLA etc.
Det er Twitter/Facebooks/Googles data og API'er og de må selvfølgelig bestemme, hvordan de kan bruges.
Man kan naturligvis bruge et gratis API som man lyster og høste nogle hurtige penge (hvis det er det man vil) imens det er frit tilgængeligt, men når den dag så kommer, hvor Twitter ex ændrer retningslinier for brugen af deres API, så må man blot trække på skuldrene og gå videre til næste projekt.
-
7
-
0
Ligesom det heller ikke er en særlig smart strategi at basere ens forretning på gratis anvendelse af et API til en service, der koster mange penge at drive.
Og selv hvis du betaler, så kan det ofte godt være smart at have en backup-plan. Det er virkeligt dumt at være afhængig af en leverandør der så pludselig skruer prisen voldsomt op. Det er stærkere hvis du så kan skifte til en konkurrent forholdsvist nemt, da du så står langt stærkere ved forhandlingsbordet.
Jeg må indrømme at jeg ikke ser det store formål i at være en "snyltervirksomhed" hvis gren bæres 100% af et andet firma, hvor store de end måtte være. Det er alt for risikabelt at være så meget bundet op på en anden virksomhed.
-
2
-
0
Nogen gange må man også bare konstatere at det der ligner et åbent API, åbenbart ikke må bruges.
DR har et API til at hente deres programmer fra DR NU.
http://www.dr.dk/nu/api
Det virkede derfor som en oplagt ide at lave en app til fjernsynet, der så ville kunne afspille alle DRs programmer. Efter at have lavet app'en til Samsung smart TV og have fået den godkendt hos Samsung, skrev jeg til DR for at få en formel godkendelse af at bruge deres API. Jeg var overbevist om at de ville klappe i deres små hænder over at der var nogen der gad bruge deres API, men nej. De afviste med begrundelsen at de understøtter åbne standarder, og problemer med rettigheder.
Man bør derfor ikke lade sig besnære alt for meget af tilsyneladende åbne APIer, uden først at have en fast aftale med firmaet bag.
Hvis nogen har lyst til at se DR NU programmer på deres Samsung eller LG tv så er det dog stadigvæk muligt at bruge min app, det er blot noget mere besværligt end det behøvede at være. App'en kan hentes her: 90.185.152.76
-
1
-
0
Det lyder godt nok underligt, DR stiller et API til rådighed, men man må ikke bruge det? Prøv at videresende den korrespondance til V2 redaktionen, det lyder som en historie der er værd at skrive.
-
1
-
0
Tilføj kommentar
