Community på Sveriges dataportal
Kommunicera driftsfönster, avvecklingar och nyutgåvor av datamängder
-
@jonass sa i Tillgänglighet, SLA-nivåer etc.:
Servicefönster utannonseras i vårt forum i god tid: https://forum.jobtechdev.se/. Större förändringar av ett API är svårkommunicerade när man inte vet vilka användarna är. Därför är forum som dataportal.se och forum.jobtechdev.se så viktiga för att kunna föra ut budskap.
Som publicist av datamängder finns det då och då tillfällen då datamängderna behöver förändras i sin form, planerade avbrott genomföras eller vissa versioner av API:erna avvecklas. I dessa tillfällen finns inget standardiserat sätt vad jag känner till att få reda på dessa förändringar.
Jag tycker att detta vore en ypperlig funktion för dataportal.se. Detta skulle även kunna tjäna som statistikpunkt för "intresse" för datamängderna för publicisterna. Olika sätt att lösa problemet på är att tvingande vid publikation tillhandahålla någon av dessa:
- Ett RSS-flöde per datamängd för poster om Driftinfo som konsumenter kan övervaka maskinellt eller i en RSS-läsare.
- E-post-lista där konsumenter kan prenumerera sin driftavdelning på information från publicisterna.
Ping @Nina_ @Maria_Dalhage m.fl. på DIGG.
-
S Stefan Wallin referenced this topic on
-
@Stefan-Wallin Det tycker jag också!
Dataportalen befinner sig i en utvecklarfas och den typ av funktionalitet som du nämner har tidigare varit uppe för diskussion. (På NOSAD-event).
Att kunna samla alla servicemeddelanden centralt, oavsett var de skapas är en toppen-idé. Någon som har idéer kring arkitektur?
-
En enkel approach skulle kunna vara att låta publicera två API-endpoints för just API:er:
/healthcheckär ju en vanlig som brukar returnera 200 när tjänsten mår bra. Denna skulle DIGG kunna pinga en gång i minuten för att se statusen./changesskulle kunna vara en JSON-array med de senaste nyheterna som DIGG kan konsumera och publicera som RSS.
För fasta datamängder så borde digg vid varje skördning eller nyuppladdning automatiskt kräva fritext på engelska och svenska för vilka ändringar som gjorts alternativt en diff mellan version
nochn+1vid automatisk skördning. -
@Maria_Dalhage
Ett annat alternativ är att integrera in klassiska GNU MailMan med en till tre e-postlistor för varje datamängd och uppmana publicister att maila till dessa vid rimliga tillfällen. -
@Stefan-Wallin I arbetet med REST API-profilen (https://dev.dataportal.se/rest-api-profil) pågår en diskussion om att organisationen som tillhandahåller ett API på ett standardiserat sätt ska kunna annonsera ett servicedatum enligt en RFC. Det skulle kunna vara en möjliggörare till funktionen Stefan är inne på.
Kandidat för "servicedatum":
https://webconcepts.info/concepts/http-header/SunsetVad tror ni om sunset ovan för API:er? (komplement till Stefans idé)
-
@jonass Finns det ett öppet API som man skulle kunna använda för att på landningsytan visa en sammanställning av alla servicedatum som är relevanta för API:er och liknande för digitala arenan?
Dvs, att de som ansvarar för API:erna lägger in servicedatum och att vi visar det per automatik i en enkel kalender? -
@Nina_Berlin Jag tror du missförstår något. Hur menar du när du säger följande?
Finns det ett öppet API...
Jag syftar på att ni när ni skördar och eller publicerar datamängder faktiskt kan ställa krav på dessa saker. Kanske genom att ge betyg/stjärnor baserat på hur driftsäker API:et är. Då skulle incitamenten börja etablera sig för hur man publicerar bra datamängder.
-
@Nina_Berlin Med ett krav i REST-API-Profilen att alla API:er ska innehålla ett datum går det att "enkelt" sammanställa en nationell överblick över kommande servicefönster eller brytande förändringar på ett ställe.
-
Fast vi kanske vill vara försiktiga med att föreslå krav - eller iallafall formulera kraven på ett sådant sätt att det inte ger merarbete för intern användning av profilen.
Som texten är nu, så är den visserligen redan riktad mot externa API:er - men som jag ser det så är den minst lika användbar som vägledning för interna API:er som aldrig syns utanför myndigheternas brandväggar.
-
@Peter_Bengtsson Bra poäng att REST-API-Profilen kan (kanske bör) användas för interna api:er också. Borde gå att hitta en formulering så att "kravet" inte medför ett extraarbete om informationen inte är relevant.
