@jenniferskoglund

Tackar för svaret! Q2 är ändå någonting att förhålla sig till.

Jag är en av de som var med och tog fram synpunkterna för Jordbruksverkets räkning, så skulle det uppstå några frågor är det bara att höra av sig.

Att reglera själva användningen av ett API är en bra fråga hur man skall göra. Ett API är ju i grund och botten en beskrivning över hur man använder en tjänst och inte någon artefakt - i motsats till exempelvis ett system som implementerar ett API. Så om licenser överhuvudtaget är applicerbara på API:er är vad jag kan se något otydligt.

Den uppenbara lösningen är kringgå problemen genom att koppla (eventuellt anonyma) nycklar till API:et, antingen för att exempelvis tekniskt begränsa antalet anrop per sekund eller för att kräva godkännande av användningsvillkor innan nyckeln lämnas ut (då har man en teknisk mekanism som man kan knyta till användarvillkoren).

Fall 1: Att använda nycklar och att ha ett öppet API är vad jag kan se inte nödvändigtvis ömsesidigt uteslutande så länge man inte principiellt begränsar åtkomst till något i API:et.

Fall 2: Detta är okomplicerat - åtkomst till innehåll och åtkomst till API:et är ortogonala problem och påverkar inte varandra.

Fall 3: Fallet med skolplattformen är intressant eftersom Stockholm stad vad jag förstått verkar försöka undvika den uppenbara lösningen - nämligen att använda API-nycklar och koppla användarvillkor till utcheckningen av dessa. Att inte ha en mekanism att koppla till användningsvillkoren blir rätt underligt, för att hitta på en liknelse:

Om vi tänker oss tillbaka till tiden när Televerket hade telefonkiosker med telefonkataloger runtom i landet. Tänk om en person med en nymodig mobiltelefon hade

• Gått in i en telefonkiosk
• Letat upp ett nummer i telefonkatalogen och sedan
• Ringt detta nummer på sin mobiltelefon.

Om Televerket då hade sagt att detta inte var tillåtet och att telefonkatalogen inte fick användas om man inte ringde med telefonen i telefonkiosken - då hade vi haft en situation som liknar den med skolplattformen.

Min gissning är att den här krumbukten grundar sig i att man blandar ihop olika koncept. Dessutom är det ju om jag förstått problemet rätt samma användare som använder samma API - men med ett annat verktyg.

Finns det en möjlighet att följa arbetet med API-profilen eller annars någon tidplan alternativt uppskattning av hur stora förändringar som förväntas som man kan ta del av?

Jordbruksverket är i ett läge där vi arbetar med att låta API:er ta en mer central roll i både applikations- och integrationsutveckling, vilket gör att behovet av förutsägbarhet kring API-profilen ökar då vi önskar utgå från den.

@jenniferskoglund

Tackar för svaret! Q2 är ändå någonting att förhålla sig till.

Jag är en av de som var med och tog fram synpunkterna för Jordbruksverkets räkning, så skulle det uppstå några frågor är det bara att höra av sig.

Finns det en möjlighet att följa arbetet med API-profilen eller annars någon tidplan alternativt uppskattning av hur stora förändringar som förväntas som man kan ta del av?

Jordbruksverket är i ett läge där vi arbetar med att låta API:er ta en mer central roll i både applikations- och integrationsutveckling, vilket gör att behovet av förutsägbarhet kring API-profilen ökar då vi önskar utgå från den.

Att reglera själva användningen av ett API är en bra fråga hur man skall göra. Ett API är ju i grund och botten en beskrivning över hur man använder en tjänst och inte någon artefakt - i motsats till exempelvis ett system som implementerar ett API. Så om licenser överhuvudtaget är applicerbara på API:er är vad jag kan se något otydligt.

Den uppenbara lösningen är kringgå problemen genom att koppla (eventuellt anonyma) nycklar till API:et, antingen för att exempelvis tekniskt begränsa antalet anrop per sekund eller för att kräva godkännande av användningsvillkor innan nyckeln lämnas ut (då har man en teknisk mekanism som man kan knyta till användarvillkoren).

Fall 1: Att använda nycklar och att ha ett öppet API är vad jag kan se inte nödvändigtvis ömsesidigt uteslutande så länge man inte principiellt begränsar åtkomst till något i API:et.

Fall 2: Detta är okomplicerat - åtkomst till innehåll och åtkomst till API:et är ortogonala problem och påverkar inte varandra.

Fall 3: Fallet med skolplattformen är intressant eftersom Stockholm stad vad jag förstått verkar försöka undvika den uppenbara lösningen - nämligen att använda API-nycklar och koppla användarvillkor till utcheckningen av dessa. Att inte ha en mekanism att koppla till användningsvillkoren blir rätt underligt, för att hitta på en liknelse:

Om vi tänker oss tillbaka till tiden när Televerket hade telefonkiosker med telefonkataloger runtom i landet. Tänk om en person med en nymodig mobiltelefon hade

• Gått in i en telefonkiosk
• Letat upp ett nummer i telefonkatalogen och sedan
• Ringt detta nummer på sin mobiltelefon.

Om Televerket då hade sagt att detta inte var tillåtet och att telefonkatalogen inte fick användas om man inte ringde med telefonen i telefonkiosken - då hade vi haft en situation som liknar den med skolplattformen.

Min gissning är att den här krumbukten grundar sig i att man blandar ihop olika koncept. Dessutom är det ju om jag förstått problemet rätt samma användare som använder samma API - men med ett annat verktyg.