Öppna data: warning endpoint
Hej, vill ni vara snälla och ordna följande endpoint till ett predictable dataformat:
http://opendata-download-warnings.smhi.se/api/alerts.json
Följande fel går att hitta idag:
1) Endpunkten respondar inte i enlighet med er dokumentation http://opendata.smhi.se/apidocs/warnings/alerts.html
1.1) "alert" är av typen array i dokumentationen, just nu är "alert" av typen objekt
1.2) Ni byter format på JSON data beroende på om det finns 0, 1 eller ..n alerts tillgängliga.
Andra fel som ofta uppkommer:
1) Ibland väljer ni helt på måfå att publicera "area" -objektet som innehåller valuet "areadesc" som ett value med CSV. Sluta med det.
Jag vågar påstå att "warnings" varit praktiskt taget oanvändbart sen åtminstone maj 2016 eftersom det helt enkelt inte går att förutspå formatet på data.
http://opendata-download-warnings.smhi.se/api/alerts.json
Följande fel går att hitta idag:
1) Endpunkten respondar inte i enlighet med er dokumentation http://opendata.smhi.se/apidocs/warnings/alerts.html
1.1) "alert" är av typen array i dokumentationen, just nu är "alert" av typen objekt
1.2) Ni byter format på JSON data beroende på om det finns 0, 1 eller ..n alerts tillgängliga.
Andra fel som ofta uppkommer:
1) Ibland väljer ni helt på måfå att publicera "area" -objektet som innehåller valuet "areadesc" som ett value med CSV. Sluta med det.
Jag vågar påstå att "warnings" varit praktiskt taget oanvändbart sen åtminstone maj 2016 eftersom det helt enkelt inte går att förutspå formatet på data.
Följ inlägget
0
följare
Tack för att du kontaktar oss, här följer ett svar till dina frågor:
-"Då varningarna endast finns tillgängliga som XML i vårt varningssystem så använder vi oss av ett tredjeparts-bibliotek för att i realtid transformera XML-datat till JSON. Detta bibliotek har den egenskapen att då det endast finns en varning utfärdad så kommer denna representeras som ett objekt snarare än en array innehållandes endast ett objekt. Tanken med detta är förmodligen att det är en mer korrekt representation av en data-struktur i JSON-format, även om det dessvärre innebär att det blir krångligare när man ska konsumera JSON-datat.
Vad gäller innehållet i areadesc så beror detta på att de hydrologiska varningarna inte är direkt kopplade till ett enskilt varningsdistrikt då de innehåller frihandsritade varningsområden som kan sträcka sig över ett eller flera varningsdistrikt. När en hydrologisk varning utfärdas så görs en beräkning på vilket eller vilka varningsdistrikt som det aktuella varningsområdet sträcker sig över, och den informationen sparas då som en kommaseparerad lista med distrikts-id:n. En meteorologisk eller oceanografisk varning är däremot alltid kopplat till enbart ett varningsdistrikt och därför innehåller areadesc i dessa fall endast ett distrikts-id."
Önskar dig en fortsatt bra tisdag!
Tack för ett utförligt svar. Har du möjlighet att uppge vilket tredjeparts lib ni använder?
Jag håller med om att det är en mer korrekt representation av datastrukturen, men det känns varken consistent eller predictable. Idag kan man som utvecklare omöjligt gissa sig till att ert API växlar mellan att responda med ett object eller en array. Som "lösning" föreslår jag att ni uppdaterar dokumentationen och beskriver de olika responsformaten en klient behöver stödja för att integrera mot era endpoints.
Mvh
Vi använder JSONProvider-biblioteket som är inkluderat i Apache CXF-ramverket.
Jag håller med dig om att vi borde vara tydliga med att API:et sköter sig på detta sätt, jag har skickat ett ärende till ansvariga om detta.