@nilsw-ra För jobtechdev.se (Arbetsförmedlingens öppna data) använder vi nedan arkitektur för att samla in och indexera loggar. Överlag är det en enkel och skalbar modell. Vi försöker att undvika att logga personuppgifter på användaren i största möjliga mån.

https://www.elastic.co/beats/filebeat -> https://www.elastic.co/logstash/ -> https://www.elastic.co/elastic-stack/

Sen har automatiserade rapporter som skapas varje dag som innehåller, antal anrop, antal användare, tillgänglighetsstatistik etc. Dessa läggs i en tråd i vårt chattverktyg mattermost. Så varje morgon 08:00-0805 uppdaterar vi oss på "hälsan" för våra API:er.

@jenniferskoglund Ok, jag såg ingen skillnad avseende de saker jag kommenterat.

Ska inte version och datum anges lite tydligare någonstans, tycker det borde finnas praxis för sådant för myndighetsdokument? Enda stället där jag kan se versionsnumret är i webbversionens länk till PDF-dokumentent. PDF-dokumentet saknar även innehållsförteckning. Det borde finnas en minimistandard att PDF:er ska innehålla en länkad innehållsförteckning för att underlätta läsning, men helst skulle man ju använda ett dokumentformat där det går att referera till innehållet.
Edit: ok innehållsförteckningen i sidan är länkad, vilket är bra, men av någon anledning får jag inte upp den i sidopanelen, så det kanske krävs någon ytterligare metadata för detta. Något som kan anges vid exporten från MS Word kanske?

Såg att fler lagt märke till att mycket är direktöversättningar från engelskspråkiga texter.

@jonass Jag har inte någon praktisk erfarenhet, men såvitt jag förstått verkar HATEOAS påminna mer om hur webben redan fungerar. I det avseendet borde det ju kännas mer intuitivt eller bekant för en användare, och utvecklingsmässigt mer likna designen för en webbplats eller webbapplikation där klienten är en webbläsare. Att gå från inget API direkt till HATEOAS kanske i så fall kan vara enklare än att bygga om ett befintligt API med statisk specifikation?

Projektet med SL:s nya API verkar visserligen ha drabbats av förseningar, om nu detta kan ha ha att göra med valet av API-design är svårt att veta såvida de inte rapporterar öppet om utvecklingsarbetet.

https://www.trafiklab.se/news/2020/2020-06-26-new-sl-apis/

The API is RESTful and supports HATEOAS implying simpler error handling and navigation of information.

The new SL API ”Public transport information Region Stockholm” replacing today’s 7 SL APIs at Trafiklab

The new SL API has been delayed to Q1 2021. We will update you when we know more.

SL launched its first open APIs in 2014 and today there are 7 APIs with a functionality that has gradually been extended. These services have been used extensively, and SL has received valuable feedback that has been used as part of the basis for the design of the new open SL API.