Etikettarkiv: api

Gästbloggat hos ISOC-SE

Jag har gästbloggat på den nya ISOC-SE bloggen. (The Sweden Chapter of the Internet Society). ISOC-SE är en svensk ideell allmännyttig förening som verkar för ett demokratiskt, sunt, lättanvänt och säkert Internet för alla – utan onödiga regleringar.

Läs mer på bloggen här: http://isoc.se/blogg.

Populära inlägg på Utvbloggen

Genom alla år som jag har bloggat här på Utvbloggen.se så har jag skrivit mer och mindre populära blogginlägg. Här kommer en mindre sammanställning på några av de blogginlägg som är populärast sett gällande hänvisningar från Google:

Post- och Telestyrelsen (PTS) släpper data via API

Post- och Telestyrelsen (PTS) väljer nu att släppa offentlig data via API. Detta är så klart mycket välkomnande och något som dess GD (gerneraldirektör) Göran Marby berättade om för några månader sedan då jag träffade honom på KommITS-mässan där vi båda höll föredrag.

Den data som de nu först släpper ut är ”Sök operatör” dvs att du kan med hjälp av ett telefonnummer fastställa vilken operatör detta nummer tillhör. Detta har flera användningsområden där ett är att du kan ringa billigare (gratis?) inom vissa operatörer och kan då använda detta nya API direkt i din mobiltelefon för att se vilken operatör dina kontakter har.

Fredrik Oljeqvist, it-chef på PTS säger:

– Vi har under året fått många förfrågningar om ett API för tjänsten ”Sök operatör” så vi har beslutat oss för att utveckla och publicera ett sådant. De flesta förfrågningarna har kommit från utvecklare som vill skapa appar för smarta telefoner. Att publicera information på detta sätt ligger i linje med E-delegationens vision om att framtidens e-förvaltning ska utvecklas tillsammans med samhällets aktörer.

Denna kommentar anser jag visar på PTS är lyhörd på inkommande förfrågningar från utvecklare samt har koll på vad som händer inom e-förvaltningsområdet specifikt det PSI-arbete som E-delegationen driver gällande vidareutnyttjande av offentliga handlingar.

Teknisk dokumentation i PDF-form hittas här samt information hittas även här. På Twitter så berättar även PTS att det ej finns några restriktioner i användningen.

Bra jobbat! Nu får vi hoppas att fler myndigheter följer PTS utveckling och öppnar upp API:er.

Så analyserar och använder du iPhone Appars API

Visste du att majoriteten av alla iPhone och iPad-appar använder någon form av API?

Jag tänkte gå igenom hur du själv kan använda dessa API:er i dina egna implementationer med hjälp av exempelvis PHP eller Python. Observera att informationen som du hämtar via API:er eventuellt inte användas till vad som helst då den kan omfattas av upphovsrätt eller andra lagar.

Först och främst så måste vi ladda hem någon form av Proxy-programmvara som medger analys av den API-trafik som går fram och tillbaka från iPhonen och Appen. Jag rekommenderar Charles Proxy som är gratis att använda men det finns även en betalversion för ynka 50$ som jag har köpt (du slipper ”nag-screens” och sådant). Charles Proxy fungerar för Linux, Mac och Windows.

Här är en skärmdump på hur det ser ut när du startat upp Charles Proxy:

Så, det första vi ska göra är att stänga av så att vi ej ser all webbsurf till och från vår egna dator och det kan man göra under Proyx-fliken och sedan se till att ”Windows Proxy” ej är förkryssad.

Nästa steg är att vi ska skicka ett E-brev med Charles SSL-certifikat till vår iPhone för att ges möjlighet att analysera krypterad HTTPS-trafik till och från telefonen. Ladda hem följande ZIP-fil: charlesproxy.com/ssl.zip och packa upp den där du sedan hittar en .CRT fil som du bifogar i ett mail som du sedan kan öppna på din iPhone (Dropbox eller annan typ av filöverföring går säkert också bra).

När du lagt in Charles certifikat i din telefon bör det se ut så här under Inställningar -> Allmän -> Profil (längst ner):

Då var det nästa steg, och det är att ta reda på IP-adressen till din dator. Jag brukar använda cmd.exe och sedan skriva ipconfig så bör det se ut något i stil med:

Denna IP-adress skall vi ange under inställningarna som det nätverk vår iPhone är ansluten till. I mitt fall så är det via WiFi och längst ner under inställningarna för det trådlösa nätverket anger jag IP-adressen till min dator som kör Charles Proxy så det ser ut så här:

Sedan är det bara att starta den App som vi vill analysera på iPhonen, i mitt fall så startar jag Swedavias App vid namn Arlanda flygplats. Och se hur Charles Proxy visar API-anropen efter varandra. Eftersom vi är intresserad av Avångar så klickar jag helt enkelt på Avångar i Arlanda Appen och får upp följande intressanta API-anrop i Charles:

Fleratalet parametrar är intressanta att anteckna eftersom de behövs vid anrop från PHP eller Python. Det varierar från app till app men i detta fall är det URL:en för anrop som innehåller flygplats (airport=arn_utr) samt datum (searchDate=2011-08-10).

Tittar vi på XML-svaret så ser det ut enligt följande:

När vi sedan implementerat en funktion som härmar denna förfrågan så bör vi få ut samma XML-svar i slutändan och kan då exempelvis hämta hem avgångar med PHP och CURL på följande sätt:

<?php
  $today = date("Y-m-d");
  $path = '/ArrivalsDeparturesMobile/ArrDepMobileService/ArrDep.asmx/GetDeparturesFlightTable?airport=arn_utr&language=sv&searchString=&searchDate='.$today;
  $host = "wsc1.swedavia.se";

  $headers = array(
    "GET $path HTTP/1.1",
    "Host: $host",
    "User-Agent: Arlanda/1.4 CFNetwork/485.13.9 Darwin/11.0.0",
    "Authorization: Basic V1NBcnJEZXBNb2JpbGU6c1AtR0U1NWJlY3I4c1BhKWhlMHBlNXJ1NkVmYUNyRSE=",
    "Accept: */*",
    "Accept-Language: sv-se",
    "Accept-Encoding: gzip, deflate",
    "Pragma: no-cache",
    "Connection: keep-alive"
  );

  $ch = curl_init();
  curl_setopt($ch, CURLOPT_URL, "http://".$host.$path);
  curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
  curl_setopt($ch, CURLOPT_HTTPHEADER, $headers);

  $sXML = curl_exec($ch);

  $oXML = new SimpleXMLElement($sXML);

  print_r($oXML);

?>

Ovan kod kan du sedan köra från kommandotolken enligt följande:

$ php swedavia.php

Tadaa! Nu slipper vi använda vår iPhone varje gång vi ska se avgångar från Arlanda. I detta exempel så behövdes ej SSL-certifikatet användas då anropen skickas i klartext.

Bloggsök API version 2

Efter en hel del strulandes och ett fallskärmshopp senare så är nu API:et för bloggsökningen uppe igen och snurrar med en hel del nya härligheter.

För att sammanfatta:

  • Booleansökningar med AND samt OR.
  • Cache-Control sätts nu i HTTP-headers till en timme.
  • Möjlighet att enbart visa antalet träffar vilket minskar belastningen i onödan.
  • XML kommer att skrotas till förmån för enbart JSON.
  • Bloggtrend API där du kan söka på godtyckligt ord och få upp antalet träffar grupperat på datum. Sträcker sig lite olika långt tillbaka i tiden beroende på antalet träffar.
  • Kommer snart: Blogglänk-API för att skapa fina länkgrafer eller om du vill se hur många, eller vilka bloggar som länkar till en viss blogg eller tidningsartikel. Detta API använder exmepelvis BloggVärde för att försöka räkna ut hur populär en blogg är.
Beskrivning av de nya funktionerna enligt följande:

Bloggtrend API

Anropas på följande sätt:

http://api.bloggz.se/api.json?q=midsommar&type=trends

Vilket då returnerar en JSON som ser ut ungefär så här (gissa vilken dag midsommarafton inträffade 2011)

Enbart antalet träffar

Om du enbart vill returnera antalet träffar för en sökfråga utan annat innehåll så slänger du på &type=hits på följande sätt:

http://api.bloggz.se/api.json?q=smsl%E5n&type=hits

Se även mitt blogginlägg om Bloggsök API version 1.

Bloggsök API

Se även Bloggsök API version 2.

En av de första webbtjänsterna jag byggde för egen räkning var Bloggz.se som är en bloggsökmotor som söker i svenska bloggar. I dagsläget så finns det runt 400 000 indexerade bloggar i dess databas. Oklart hur många av dessa som är aktiva men bloggar som ger felmeddelanden såsom 404 rensas fortlöpande bort. Även viss spam-filtrering sker. Nya bloggar upptäcks automatiskt med hjälp av ping.bloggnytt.se, en crawler samt BloggPing.

Antalet blogginlägg är i dagsläget 54 483 829 och innehåller inlägg från 2007 och framåt.

API:et nås på följande URL:

http://api.bloggz.se/api.json eller api.xml för XML-versionen. Det är fritt fram att använda API:et för icke kommersiellt bruk.

Möjliga parametrar är:

  • ?q=sökfrågan
  • Pagination med &p=1 upp till 100
  • Sortering efter datum eller relevans med hjälp av &sort=rel, standardsortering är datum. Nyast först

Skärmdump från JSON-data:


Om du använder API:et, så sätt gärna en User-Agent header med kontaktuppgifter såsom E-post.

Uppdatering: Håller på att uppdatera API:et så det kommer att fungera dåligt eller inte alls under 2-3 dgr.

Uppdatering 2: Nu fungerar det igen.

10 saker att tänka på vid skapande av API

Så du går i tankarna på att tillhandahålla ett API? Då har du kommit rätt. Jag försöker här att redogöra över de tankar jag har när det gäller det mesta vid API utveckling.

Först och främst så bör du ställa dig frågan om ett API verkligen är rätt, och i de flesta fall så skulle jag säga att API är rätt väg. De fall då ett API kanske inte är lämpligt är då din tjänst enbart bygger på ett annat API och ej tillför något mervärde. Prioritering är också en viktig punkt, i flertalet fall så kan det tillåmed vara så att ett API skall finnas innan en webbsida finnes (framförallt i offentlig sektor).

Om du tillhandahåller en iPhone-app eller någon annan typ av extern tjänst så är detta också tillämpningsbart.

1. Placera ditt API under ett eget DNS-namn, exempelvis api.domän.se. Även om api.domän.se pekar till domän.se till en början.

2. Detta har med ovan punkt att göra: Exportera din data till en separat server som exempelvis ligger i molnet. Detta för att enkelt göra ditt API redundant och icke beroende av din ordinarie tjänst som kanske får problem om du får tusentals API-förfrågningar per sekund. Kan dock bli problem med realtidstjänster om API:et tillhandahåller sekundaktuell information.

3. Fundera om du bör tillhandahålla en krypterad version över HTTPS. Fundera även över om anrop bör vara signerade, för https i sitt standardutförande verifierar ej klient, bara server. Självklart kan du köpa SSL-certifikat via min sajt https.se.

4. Vilket format är lämpligast. JSON REST, XML SOAP eller annat? Jag rekommenderar REST JSON. Se Google eller FRAPI

5. Vill du hålla koll på vilka som anropar ditt API? Då bör du tillhandahålla en API-nyckel och bygga en registreringsprocess för detta. Enklast är att använda Google Forms. Det finns ofantligt många sätt att bygga detta förfarande.

6. Du bör införa kontroll av anrop samt begränsningar. Detta kan vara bra för att förhindra miljontals anrop i sekunden eller forcering av lösenord/användarnamn. Begränsa förfrågningar på så mycket som du bara kan, exempelvis IP-nummer.

7. Vilken licens kan användas? Här kan myndigheter få problem då CC-licenser kan gå emot lagstiftning. E-delegationen håller på med ett arbete om bl.a. detta och kommer att tillhandahålla mer information.

8. Upprätta en changelog, blogg eller E-postlista (Google Groups) för att berätta om eventuella förändringar. Här kan det även vara bra att prefixa alla API-anrop med versionsnummer för att bibehålla bakåtkompabilitet. Exempelvis: api.domän.se/v1/anropstyp

9. Glöm framförallt inte att erbjuda dokumentation och kod-exempel på hur API:et används. Berätta om innehållet, begränsningar, datatyper, relationer, statuskoder osv. Kanske ett forum för frågor? Wiki? Status-sida för att berätta om eventuella problem med ditt API eller fördröjningar. Se Pingdom eller Watchmouse.

10. Övriga punkter: Länka till de som använder ditt API för att uppmuntra användning. Ta betalt för ditt API? Berätta för Mashup.se att du har ett API. Hur länge bör du cacha? Pagination, page=1 vs.  cursor: start_id=1234. Loggning? If-Modified-Since header?

That’s it! Har säkert glömt många bra saker, skriv en kommentar och berätta vad du saknar.

Öppen data från myndigheter via API

Nedan presentation höll jag på E-delegationens möte ”Öppet möte om öppen data”. För att försöka förklara innebörden av API och öppen data hos myndigheter.

E-delegationen berättade bl.a. om deras uppdrag samt vad de gör inom området. Andra föredragshållare listas även nedan, förhoppningsvis så lägger även E-delegationen upp samtliga presentationer.

Agenda för mötet:

  1. Presentation om delegationens arbete, status och vision E-delegationens kanslichef Claes Thagemark
  2. Presentation om öppen data Daniel Akenine, NTO, Microsoft AB
  3. Tankar om PSI-lagen och hur den skulle kunna implementeras Mathias Ekman, Modul1
  4. PSI och öppenhet, vikten av standarder i det fortsatta PSI-arbetet Andreas Lundgren, IBM
  5. Thomas Gäfvert, Lemontree
  6. Järnvägsinformation och geodata Roger Fagerud, Trafikverket
  7. Syn på vidareutnyttjande av offentlig data Rolf Nordqvist, PSI Alliance
  8. Presentation om öppen data Claes-Olof Olsson, Föreningen Sambruk, Sandvikens kommun
  9. Datakvalité, informationsaggregering, förutsättningar för utnyttjande av data från flera källor Staffan Malmgren, Domstolsverket
  10. Jonas Lejon, Triop AB