Obojętnie w czym by Pan tego nie pisał polecam pewną metodykę ( aczkolwiek można mieć inne podejście, z pewnością na forum są osoby bardziej kompetentne ode mnie, która mnie poprawią - za co już z góry szczerze dziękuję ) :
- API
- Jeśli API nie ma ograniczeń odnośnie zapytań ( czasowe tokeny, ograniczenia ilościowe requestów ) to może Pan obrobić dane w locie ( tutaj ograniczeniem jest serwer lub maszyna klienta, na której dochodzi do obrabiania )
- Jeśli API ma natomiast ograniczenia dobrze jest gdzieś zrzucić dane i pobierać je możliwie najbardziej sensownie:
- optymalizować zapytanie do API
- lepiej pobrać więcej, niż czekać na upłynięcie czasu ze względu na limit API
- W zależności od wrażliwości danych musi Pan zadecydować, gdzie dane przetrzymywać:
- Pierwszym naturalnym krokiem jest zrzucenie danych lokalnie do plików ( txt, csv, xml, json), ale to rozwiązanie dla niewrażliwych danych.
- W razie danych klucz1=wartosc, klucz2=wartosc warto pomyśleć o MongoDB lub ElasticSearch.
- Jeśli dane w przyszłości będą służyć do różnych (dziwnych) systemów warto pomyśleć o relacyjnej bazie.
- Znaczenie ma z gruntu jaka baza danych jest używana przy całym projekcie. Jeśli jest to baza relacyjna, warto przetestować jaki będzie to miało na nią wpływ i raczej się jej trzymać. Projekt jest projekt.
- Mechanizm
- Proponowałbym Panu zbudowanie bardzo uproszczonego kontrola. Klasa, kilka funkcji do api ( connect, disconnect, put, get i inne ) i funkcje do bazy ( chyba, że ma Pan klasę do tego, to pominąć ). Wszystko wedle własnego uznania, aby ominąć z czasem rozrostu projektu DRY.
- Obowiązkowe jest pisanie prostych testów. Sprawdzanie poprawności danych, to czynność ważniejsza niż obróbka czy przetrzymywanie danych w bazie. Za każdym razem, gdy odpytuję Pan API warto sprawdzić:
- Czy otrzymuję Pan status 200 od API
- Czy pana pozwala zrobić testowy update ( uprawnienia, aktywnych host itd )
- Sprawdzenie struktury drzewa, obiektu, tablicy poprzez hash. Jeśli hash się zmienił coś uległo zmianie. Co uległo? Jak się przed tym bronić? Jaki to ma wpływ na mechanizmy pobierania i wysyłania?
- Jakość danych, które Pan pobierze jest najważniejsza, bo to one odgrywają pierwsze skrzypce. Tutaj wchodzą obowiązkowo regexy np. dane posiadają tylko spacje i znaki alfanumeryczne jak pierwotnie czy jest coś extra i co jest extra, gdzieś to "wypluć" - do jakiegoś loga, z opisem i czasem, inputem i outputem.
- Na bazie tego co mamy w logach możemy dozbrajać testy i ulepszać nasze mechanizmy.
- Błędne dane mimo wszystko warto zrzucić do bliźniaczej tabeli_nv ( novalid // lub innych tego typu log ).
- Naturalna metoda w druga stronę. Zanim wyślemy cokolwiek do API, opisujemy to testami i w razie błędów, zrzucamy to do jakiejś tabeli ( metodyka try catch ) i odczytujemy co nam wypluł error w konkretnym przypadku. Pomoże to lepiej przygotować testy.
Wielu pomyśli, że to nadgorliwość tak dokładnie pracować z API i być tak szczegółowym. Jeśli będziemy pisać kod 'dla własnego użytku' to pisanie testów nie świadczy o naszej nadgorliwości, lecz o oczekiwaniach, które sobie stawiamy.