Metody zapisywania danych z zewnętrznego api

Question

Chcę pobrać zewnętrzne api przy użyciu laravel z tej strony https://petstore.swagger.io/#/ do wyświetlania, dodawania i usuwania pets. I mam pytanie czy te dane należy jakoś zapisać do bazy danych czy jednak nie ? Jak do tego podejsc w najlepszy sposób?

Answer 1

Nie do końca rozumiem co masz na myśli pisząc "chcę pobrać zewnętrzne API". Tj. chcesz zrobić frontend do tego API? Czy chcesz pobrać wszystkie dane które ten backend ma w swojej bazie danych?

Jeśli to pierwsze, to poza opcjonalnym lekkim cache'owaniem nic nie musisz pobierać do bazy, bo to API to jest Twoja "baza". Więc po prostu zamiast z mysql/etc, korzystasz z tego API (zauważ, że mysql/etc to też zewnętrzne API, tyle, że ukryte pod gotowymi funkcjami, które zajmują się komunikacją sieciową).

Comments

Chcę z tego api zewnętrznego pobrać dane, dodawać i usuwać, i poprostu mam pytanie czy te operacje mam wykonywać na swojej bazie danych czy ta baza nie jest potrzebna ?

---

Kluczowa jest ta część "dodawać i usuwać" – jeśli chcesz dodawać dane do ich backendu (tj. za pomocą tego API) oraz usuwać dane z ich backend (tj. za pomocą tego API) – co jest btw tym jak zazwyczaj takie API się używa – to nie potrzebujesz własnej bazy do tego. Po prostu musisz odpowiednie API sobie wywołać.

Answer 2

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ę ) :

1. API
   1. 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 )
   2. Jeśli API ma natomiast ograniczenia dobrze jest gdzieś zrzucić dane i pobierać je możliwie najbardziej sensownie:
      1. optymalizować zapytanie do API
      2. lepiej pobrać więcej, niż czekać na upłynięcie czasu ze względu na limit API
   3. W zależności od wrażliwości danych musi Pan zadecydować, gdzie dane przetrzymywać:
      1. Pierwszym naturalnym krokiem jest zrzucenie danych lokalnie do plików ( txt, csv, xml, json), ale to rozwiązanie dla niewrażliwych danych.
      2. W razie danych klucz1=wartosc, klucz2=wartosc warto pomyśleć o MongoDB lub ElasticSearch.
      3. Jeśli dane w przyszłości będą służyć do różnych (dziwnych) systemów warto pomyśleć o relacyjnej bazie.
      4. 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.
2. Mechanizm
   1. 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.
   2. 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ć:
      1. Czy otrzymuję Pan status 200 od API
      2. Czy pana pozwala zrobić testowy update ( uprawnienia, aktywnych host itd )
      3. 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?
      4. 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.
      5. Na bazie tego co mamy w logach możemy dozbrajać testy i ulepszać nasze mechanizmy.
      6. Błędne dane mimo wszystko warto zrzucić do bliźniaczej tabeli_nv ( novalid // lub innych tego typu log ).
   3. 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.