Support for MIST APs through API-polling

[KristianLyng]

This probably means adding a new collector to fetch API data and store it in a new API endpoint.

[KristianLyng]

https://github.com/mistsys/mist-public

[theS1LV3R]

https://www.mist.com/documentation/mist-api-introduction/

[KristianLyng]

Denne tasken må nesten deles i tre:

1. Kartlegge hva i APIet til mist vi vil ha - her tenker jeg "leveransen" er at saken oppdateres med en konkret "dette er interessante verdier"/api-endepunkter vi burde polle i første omgang, om ikke man hopper rett til punkt 2...
2. Lage en poller som periodisk henter relevant data fra APIet og lagrer det i en postgresql-tabell. Tenker den fint kan være ganske mist-spesifikk, men en viss grad av "oi, kanskje vi vil ha DET API-endepunktet også" vil nok forekomme.
3. Eksponere dataene via det tradisjonelle gondul-apiet så det kan behandles likt som alt annet i APIet - dette kan jeg bistå med så fort dataene er i Postgres.
4. Lage en nms-map-handler som bruker dette.

Tradisjonelt har pollerene vært skrevet i perl, men det er absolutt ingen grunn til å gjøre det - templatingen er skrevet i python f.eks., men det er derimot viktig at resultatet kan lagres i postgres. Helst bør det være formatert på en måte så man kan iterere over APer også - det passer Gondul-modellen godt. Merk at det ikke nødvendigvis må begrenses til bare én tabell altså.

[KristianLyng]

... deles i tre, etterfulgt av en liste på fire punkter. Bra jobba, Kristian.

[theS1LV3R]

Sjekket APIene nå, dokumentasjonen er en mess, og det virker som de bruker websockets til omtrent alt. Auth blir også mye vanskeligere mtp. at de ikke bruker tradisjonelle API tokens, men et /login endepunkt. Pain.

[theS1LV3R]

Sjekket igjen nå, de har en del APIer som de bruker i web-interfacet sitt. Såpass mange at det blir veldig komplisert å gjøre noe med de. (Typ side A henter data fra API A1 som gir en ID til API A2 som har en reference til API A3 som endelig gir data til side A)