REST, webhook czy plik — jak wybrać sposób wymiany danych

Przy każdej integracji pada to samo pytanie: jak połączyć dwa systemy? Odpowiedź rzadko jest kwestią gustu — zwykle wynika z tego, co druga strona w ogóle udostępnia. Poniżej przegląd sposobów wymiany danych i wskazówki, kiedy który wybrać.

REST API — domyślny wybór

Standard w nowoczesnych systemach. Odpytujesz adres, dostajesz JSON, wysyłasz dane tą samą drogą.

• Kiedy: gdy druga strona ma udokumentowane API i potrzebujesz danych na żądanie.
• Zalety: czytelność, dobre wsparcie narzędziowe, łatwa diagnostyka.
• Uwaga na: limity zapytań, stronicowanie wyników i to, że odpytywanie „co minutę na wszelki wypadek” potrafi wyczerpać limit dzienny.

Webhook — gdy liczy się czas reakcji

Odwrócenie kierunku: to system źródłowy powiadamia Cię o zdarzeniu, zamiast czekać na zapytanie.

• Kiedy: płatność zaksięgowana, zamówienie złożone, status przesyłki zmieniony — wszędzie tam, gdzie opóźnienie ma znaczenie.
• Zalety: natychmiastowość i brak zbędnych zapytań.
• Uwaga na: musisz wystawić adres dostępny z internetu, zweryfikować podpis wiadomości i przyjąć, że to samo zdarzenie może przyjść dwa razy.

Webhook wymaga idempotentności. Jeżeli nadawca nie otrzyma potwierdzenia w kilka sekund, ponowi wysyłkę. Bez zabezpieczenia utworzysz drugie zamówienie z tego samego zdarzenia. Zapisuj identyfikator zdarzenia i ignoruj powtórki.

SOAP — starsze systemy i rejestry publiczne

Wyglądem odstrasza, ale bywa jedyną dostępną drogą — zwłaszcza w systemach branżowych i części usług publicznych. Jest ściśle zdefiniowany, co ułatwia walidację, ale jest gadatliwy i mniej wygodny w diagnostyce.

Wymiana plikowa — niedoceniana i często wystarczająca

CSV lub Excel odkładany o ustalonej porze do katalogu, na serwer FTP albo do biblioteki SharePoint.

• Kiedy: system nie ma API, a dane wystarczy wymieniać raz na dobę.
• Zalety: działa praktycznie zawsze, jest tanie i łatwe do podejrzenia — plik można po prostu otworzyć.
• Uwaga na: kodowanie znaków (polskie znaki w plikach CSV to klasyka problemów), format daty i separator dziesiętny, a także rozstrzygnięcie, co zrobić z plikiem, który nie przyszedł.

Nie warto lekceważyć tej drogi. Wiele integracji, które musiały zadziałać „na wczoraj”, ruszyło właśnie tak i pracuje latami.

Bezpośrednio na bazie — ostateczność

Czasem jedyne wyjście, gdy producent nie udostępnia niczego innego.

• Do odczytu: akceptowalne, o ile korzystasz z konta z uprawnieniami wyłącznie do odczytu i najlepiej z repliki.
• Do zapisu: ryzykowne. Omijasz reguły biznesowe aplikacji i możesz naruszyć spójność danych, a producent najpewniej odmówi wsparcia.
• Zawsze: aktualizacja systemu może zmienić strukturę tabel bez ostrzeżenia. Więcej przy integracjach baz danych.

Zestawienie

Sposób	Czas reakcji	Trudność	Typowe zastosowanie
REST	sekundy	niska	Pobieranie i zapis danych na żądanie
Webhook	natychmiast	średnia	Reakcja na zdarzenia
SOAP	sekundy	średnia	Starsze systemy, rejestry
Pliki	godziny	niska	Wymiana wsadowa raz na dobę
Baza	sekundy	wysoka (ryzyko)	Gdy nie ma innej drogi

Pytania, które trzeba zadać przed wyborem

1. Jak szybko dane muszą być po drugiej stronie? Jeżeli wystarczy raz na dobę, nie buduj integracji czasu rzeczywistego.
2. Ile rekordów dziennie? Kilkadziesiąt i kilkaset tysięcy to zupełnie inne rozwiązania.
3. W którą stronę płyną dane? Wymiana dwukierunkowa wymaga rozstrzygnięcia konfliktów — to zwykle najtrudniejsza część.
4. Który system jest źródłem prawdy? Bez tej decyzji integracja prędzej czy później rozjedzie dane.
5. Co się dzieje przy awarii? Dane mają poczekać w kolejce, a ktoś ma się o tym dowiedzieć.
6. Kto to utrzyma? API po drugiej stronie będzie się zmieniać. Integracja bez opieki kiedyś przestanie działać.

Najczęstszy błąd

Budowanie integracji czasu rzeczywistego tam, gdzie wystarczyłby nocny import pliku. Rozwiązanie jest wtedy droższe, bardziej awaryjne i trudniejsze w utrzymaniu — bez realnej korzyści. Zacznij od pytania o wymagany czas reakcji, nie od wyboru technologii.