REST-api (+ API:ts historia)

Jag använder http://api.sr.se/api/v2/scheduledepisodes?pagination=false&format=json&channelid=164 för att få tag på nuvarande dygns programtablå för P3. För varje program sparar jag program-id och episode-id. Sedan använder jag efter det http://api.sr.se/api/v2/episodes/index?pagination=false&format=json&programid=5380 för t.ex. Nyheter från Ekot. Sedan letar jag i svaret efter episode-id från föregående fråga men, det är definitivt inte alltid jag hittar något. Hur kan det komma sig? Vad gör jag för fel? Jag håller på med en YH-utbildning för React och webutveckling och tänkte använda ert REST-api för att ha lite rolig data.

Kommentarer

  • Hej!

    Vi har ett fel/ologiskt resultat (v2 är så gammalt att ingen riktigt minns) i schedulepisodes. Den matchar egentligen hur tablån ser ut visuellt - med sändningar som är 'barn' till andra sändningar.

    Om du tittar på tablån från midnatt så ser du att Vaken går 00.02 - 05.59, och har Nyheter från Ekot en gång i timman.

    I schedulepisode ger vi alla Ekotsändningar samma EpisodeID som Vaken, för att man ska kunna skriva ut det grupperat. Så det ID du letar efter hos Ekot finns inte där, utan det är Vakens sändning.

    Egentligen borde vi ju ha skrivit ut det riktiga EpisodeID och sedan förälderns ID, men som sagt det är ingen som minns varför vi gjorde det såhär...

    Detta problem har kommit upp ett par gånger tidigare i höst, men eftersom vi håller på och bygger ett nytt öppet API så har vi bestämt att vi inte kommer att ändra schedulepisodes, tyvärr.

    (Säg till om jag inte förklarade felet tillräckligt bra!)


    mvh
  • Hej, jag har också haft lite svårt att nysta upp strukturen i det nuvarande API:et (som antagligen är från 2014 när PSI-direktivet kom, och enligt rykten skapat av några tillfälligen närvarande praktikanter på SR).

    Har ni någon information om det nya API:et?
    T.ex. hur det skiljer sig från det nuvarande.
  • Hej!

    Frågor om hur API:t fungerar kan jag inte besvara, men jag vill korrigera ett par missuppfattningar, i och med att jag har varit med och sett API:t växa fram.

    2014 och några tillfälligen närvarande praktikanter på SR går lätt att kolla upp.

    Sveriges Radio har nämligen haft ett öppet API sedan Music Hackday i januari 2010. Här skrev Ny Teknik om detta evenemang:
    Snickra en musiktjänst på ett dygn
    Under Music Hack Day kommer Magnus Suneson visa upp SR:s nya API för första gången.

    – Vi gör metadata om våra kanaler tillgänglig, bland annat tablåer och spellistor. Vi hoppas få feedback på det vi gjort, och sen ska vi förbättra det under våren, säger han.
    Magnus, som numera är produktägare för våra röststyrda tjänster, har arbetat på Sveriges Radio i 20 år. Det är rätt lång tid för en tillfällig praktikant.

    Den andra "praktikanten" som paketerade vårt första API, heter Josefina Moström. Hon var rätt nyanställd 2010. Idag är hon IT-arkitekt. Båda är mycket seriösa och smarta personer (och dessutom trevliga).

    (De där "praktikanterna" - ibland kallade forskare på KTH - brukar annars oftast få cred för vår Alexa-tjänst, som egentligen är framtagen av samme Magnus Sunesson, ihop med Tobias Björnsson och Jonas Lindholm.)

    Att version 2 kom senast 2012, framgår här:
    Versionshantering av SR-API

    Johannes:
    Jag blir förbryllad över den kritik du kommer med, eftersom den pendlar mellan att vara väldigt konstruktiv och berättigad, och ibland ger närmast fejk news-wibbar. Vad är syftet med att sprida ett rykte du uppenbarligen inte tagit dig tid att kolla upp? Och varifrån har du fått denna felaktiga information?

    Nåväl, nu har jag fått berätta om bakgrunden. Jag hoppas att någon annan kan berätta mer om framtiden 😀

    Trevlig helg!
    Annika Webbmaster
  • Tror jag läste något åt det hållet i ett inlägg på forumet tidigare, kan hända att jag blandat ihop "hopsnickrat på en dag i en hackathon" med praktikanter, ledsen för det men kanske en bit av andemeningen kvarstår.

    Anledningen till att jag skriver lite provokativt är jag tycker den förklaring eller beskrivning jag tidigare sett känns otillfredsställande och gärna skulle vilja höra en bättre och mer klargörande version från Sveriges Radios sida. Denna gång fick jag det, åtminstone gällande bakgrunden, och med lite tydlig information verkar det ju inte så svårt att förebygga vidare ryktesspridning.

    Jag har inget intresse i att sprida rykten, mitt intresse ligger i att få dem vederlagda eller bekräftade, men jag kan försöka tänka på att uttrycka mig i lite mer frågande formuleringar framöver, i förhoppning att även i det fallet uppmärksammas med klargörande svar från de säkert sympatiska och alldeles vanliga människor som lever och verkar innanför Sveriges Radios väggar.

    PSI-direktivet kom kanske 2010 då, det verkar så på namngivningen på den svenska lagen (2010:566). Jag hade fått intryck av att öppna data var på tapeten runt 2014, varefter uppmärksamheten från myndigheternas sida verkar ha klingat av. En artikel om PSI-direktivet på rikdagens webbplats är daterad jan 2015. Jag förmodar att Alexa och röststyrning anses vara mer i ropet för närvarande, en tjänst som jag dock inte använder mig av själv. Jag är även skeptisk till att skattemedel läggs på utveckling inom proprietära teknologier som Sonos och liknande system.

    Tack för nedlagda efterforskningar. Kul att det gått bra för personerna bakom det ursprungliga API:et och att de var tidigt ute. Tråkigt att det är svårt för utomstående att få uppdateringar om utvecklingen sedan dess.

  • Vad är syftet med att sprida ett rykte du uppenbarligen inte tagit dig tid att kolla upp?
    Tror jag läste något åt det hållet i ett inlägg på forumet tidigare, kan hända att jag blandat ihop "hopsnickrat på en dag i en hackathon" med praktikanter, ledsen för det men kanske en bit av andemeningen kvarstår.
    Jag ber om ursäkt över att jag tolkade din missuppfattning som ryktesspridning.

    Deltagarna vid detta Hackaton hade ett dygn på sig att bygga musiktjänster, och använde sig då av bland annat det API vi gjorde publikt där och då, men det API som vi levererade till detta Hackaton var inte hopsnickrat på en dag.

    Jag skrev ihop en text om API:ts historia 2017, som en sammanfattning av en dragning jag höll för våra utvecklare på något som kallades "kompetensfredag". Detta kan vara intressant även för lyssnare, så väl bekomme!
    Även innan vi hade ett öppet API, utvecklades olika webb-tjänster (som widgets) av oberoende utvecklare. De flesta av dessa tjänster var plattformsspecifika.

    Ett stort problem med dessa tjänster var att de slutade fungera när vi gjorde tekniska förändringar, som när vi bytte ljudformat.
    • Vista Sidebar Radio (jan 2007) Johan Eriksson?
    • "Kentas webbradio" SRadio (jan 2008?)
    • Stefans SR WebbRadio (när? Innan 2010)
    I samband med att Iphone och Android blev viktiga aktörer växte det fram fristående appar för dessa operativsystem. SR Poddradio (2008) som sen utvecklats till Sveriges Radio Play för Ios och SR Player (2009) som utvecklats till Sveriges Radio Play för Android.

    Eftersom det saknades ett samlat grepp om hur man hämtade vårt innehåll, använde indie-utvecklarna en salig blandning av podd-rss:er och ”avsniffade” länkar. Här har Android-utvecklarna turen att komma i kontakt med vår kollega Christian Gillinger, som bistår med den länk som text-tv använde för tablåer:
    http://www.swedroid.se/forum/threads/sveriges-radio-foer-android-vilka-features.537/page-8#post-30922

    (Android-appens framväxt går för övrigt att följa på Swedroid-forumet, vilket jag tycker är intressant läsning!)

    Att strukturera dessa olika metoder och länkar och presentera dem på ett begripligt vis blev allt viktigare, både för oss själva och för externa utvecklare. Vi skapade därför ett öppet API. Den första versionen släpptes i januari 2010, både för att hjälpa externa utvecklare och för att vi själva hade ett behov (just då i samband med Music Hackday, men syftet var långsiktigt).

    Version 2 av API:et släpptes som beta i juni 2012, med lansering skarpt i oktober samma år.

    Vi insåg med tiden att villkoren för vårt API, som redan från början varit minimalistiska, behövde förenklas ytterligare. Det stod nämligen att API:et inte fick användas kommersiellt, vilket hämmade många utvecklare. Genom att stryka denna passus (2013), blev det enklare för alla att använda API:et
    Sveriges Radio uppmuntrar till användande av Öppet API

    Se här för diskussion om vad skillnaden kan innebära:
    Vilken skillnad några få ord gör – Sveriges Radios API-villkor

    Villkoren är nu:
    ”Materialet som tillhandahålls via API får inte användas på ett sådant sätt att det skulle kunna skada Sveriges Radios oberoende eller trovärdighet.”

    Några indie-appar som använder API:t idag:
    • Trafiknytt Sthlm (2011) Android
    • Replay David Ask (2012) Ios
    • Poddradion (2013) Windows Phone
    • Radio i menyraden (dec 2013) Mac
    • Sveriges Radio Spelare (våren 2014) Chrome
    • Lyssna (april 2014) Android
    • SR.nu (maj 2015) tablå-app, Android
    • RadioStorm (hösten 2015) Windows 10 m fl
    Senaste tillskottet jag har hört talas om kom förra veckan (alltså efter min dragning under kompetens-fredagen):
    Squeezebox-plugin med Sveriges Radios kanaler och poddar
    Tack för att du fick mig att leta upp detta igen! Alla de här Stefans SR WebbRadio etc väcker minnen, eftersom jag på ett eller annat vis gett support även på de tjänsterna. Eller försökt, åtminstone 😀

    Trevlig helg!
    Annika Webbmaster
  • Ok, tack för historiken, det var intressant läsning.
    Vi kan väl konstatera att API:et i sin nuvarande utformning publicerades för 8 år sedan.
    Min egentliga frågeställning var väl om det läggs någon tid på att utveckla API:et i dagsläget, och i vilken riktning utvecklingen sker. Har ni tagit ställning till principer som HATEOAS till exempel, eller handlar det mer om funktioner för nya plattformar och enheter?
  • Arbetet med det nya öppna API:et är pausat just nu, men det handlar främst om att förenkla och ta bort de funktioner som inte fungerar längre - och våra egna tjänster ska sluta använda det helt och istället använda ett eget API.

    mvh
  • Ok, förenkla och ta bort låter ju lite olycksbådande.
    Vad är skälen till att övergå till ett internt, icke offentligt API och lägga utvecklingen där istället?

  • Dels så har vi nu så pass många tjänster, och en del av dem har specifika behov vilket är ohållbart på att bygga på detta api med, och så finns det saker som bara är för våra egna tjänster, som personalisering etc.

    mvh

Kommentera eller skriv ett nytt inlägg

Ditt namn och inlägg kan ses av alla. Din e-post visas aldrig publikt.