Django REST API: povezivanje poslovnih sustava

Kada aplikacija treba razmjenjivati podatke s ERP-om, računovodstvom, mobilnim sučeljem ili vanjskim servisom, API postaje važan dio arhitekture. Django se može koristiti za izgradnju REST sučelja, često uz Django REST Framework. Dobro projektiran API omogućuje integracije bez direktnog dijeljenja pristupa bazi.

Prije endpointa definirajte poslovni ugovor

Najprije odredite koje podatke drugi sustav treba i što s njima smije napraviti. Primjerice, vanjski sustav smije dohvatiti status narudžbe, ali ne i mijenjati njezinu cijenu. Definirajte identifikatore, obvezna polja, formate datuma, pravila paginacije i odgovore na pogreške.

API nije samo ruta /api/narudzbe/. On je ugovor između sustava koji se mogu nadograđivati različitim tempom. Zato svaka promjena koja može slomiti klijenta zahtijeva poseban plan kompatibilnosti.

Autentifikacija i autorizacija su odvojena pitanja

Autentifikacija odgovara na pitanje tko šalje zahtjev. Autorizacija odlučuje ima li taj korisnik ili sustav pravo obaviti određenu radnju nad konkretnim zapisom. API ključ, token ili OAuth pristup nije automatska dozvola za sve podatke.

Primjerice, korisnik može vidjeti vlastite narudžbe, ali ne i narudžbe drugih klijenata. Provjera mora biti na serveru i u upitu prema bazi, ne samo u mobilnoj ili web aplikaciji. Posebno pazite na masovno dohvaćanje, nesigurne identifikatore i povrat osjetljivih polja.

Pouzdanost integracija

Vanjski servis može privremeno biti nedostupan. Zato odredite timeout, politiku ponovnog pokušaja i ponašanje nakon trajne pogreške. Kod radnji koje stvaraju novčane ili poslovne posljedice važna je idempotentnost: ponovljeni zahtjev ne smije nehotice izraditi drugu narudžbu.

Ako integracija prima obavijesti putem webhooka, provjeravajte potpis ili drugi dogovoreni mehanizam autentičnosti te bilježite identifikatore već obrađenih događaja. Ne vjerujte sadržaju zahtjeva samo zato što dolazi na tajnu adresu.

Performanse i dokumentacija

API koji vraća tisuće zapisa bez paginacije može opteretiti bazu i klijenta. Koristite razumne limite, filtre i jasne iznimke. Kod Django ORM-a pazite na N+1 upite prilikom serijalizacije povezanih modela. Bilježite trajanje zahtjeva i stopu pogrešaka.

OpenAPI specifikacija olakšava integratorima razumijevanje dostupnih operacija. Dodajte primjere zahtjeva, tipične poruke pogreške i postupak testiranja u odvojenom okruženju, bez stvarnih osobnih podataka.

Kada razvijati API?

Ako više sustava redovito razmjenjuje strukturirane podatke, jasna API granica često olakšava budući razvoj. Ako treba samo jednom mjesečno uvesti datoteku, jednostavniji kontrolirani uvoz možda je sasvim dovoljan. Dobar API nastaje kada rješava stvarnu potrebu za sigurnom i predvidljivom razmjenom podataka.

Integracija kao poslovni proces

Interna aplikacija za rezervacije treba poslati potvrđene podatke računovodstvu. Najprije se definira koji događaj pokreće prijenos, koje su vrijednosti obvezne i kako se povezuju identifikatori između sustava. Ako je računovodstveni servis privremeno nedostupan, događaj se ne smije izgubiti niti se isti račun smije stvoriti dvaput. To je razlog za redove zadataka, identifikatore integracijskih poruka i jasno evidentirane statuse.

U testnom okruženju treba provjeriti i neobične slučajeve: naknadnu promjenu adrese, storniranje, nepostojeći povezani zapis ili neispravne podatke. Tek kada su definirana pravila za pogreške, integracija je spremna za produkciju.

Česta pitanja

Je li REST API isto što i baza? Nije. API izlaže kontrolirane operacije, dok unutarnja struktura baze može ostati skrivena.

Može li API biti privatan? Da. Može se ograničiti na privatnu mrežu i dodatno zaštititi autentifikacijom i autorizacijom.

Treba li verzionirati API? Kod promjena koje utječu na klijente svakako treba imati strategiju kompatibilnosti i komunikacije s integratorima.

Kako provjeriti kvalitetu API integracije?

Integracija dva poslovna sustava može izgledati jednostavno dok sve radi. Kvaliteta se vidi kada jedan sustav kasni, vrati neočekivan status ili pošalje duplikat. Zato treba unaprijed dogovoriti način prepoznavanja zapisa, obradu pogrešaka i postupak usklađivanja podataka nakon prekida.

• Jesu li svi obvezni podaci, identifikatori, datumi i statusi dokumentirani i testirani sa stvarnim primjerima bez osjetljivih podataka?
• Provjerava li se autorizacija za svaki pojedini zapis, uključujući pokušaje pristupa tuđim identifikatorima i izvozu podataka?
• Koristi li sustav vremenska ograničenja, kontrolirane ponovne pokušaje i zaštitu od dvostrukog izvršenja zahtjeva?
• Kako se bilježi poruka koju vanjski servis nije prihvatio i tko odlučuje o njezinoj ponovnoj obradi?
• Postoji li testno okruženje i proces obavještavanja integratora o promjenama API formata ili semantike?
• Može li se u logovima pronaći određena transakcija bez nepotrebnog zapisivanja lozinki, tokena ili osobnih podataka?

Dobra integracija ne zahtijeva stalnu ručnu intervenciju i omogućuje siguran oporavak kada vanjski servis zakaže.

Za svaku integraciju odredite vlasnika poslovnih podataka. Ako dva sustava dopuštaju promjenu iste adrese kupca, tko ima prednost u slučaju sukoba? Bez tog pravila API može ispravno prenositi poruke, a poslovni podaci svejedno postati nekonzistentni. Ovo pitanje treba riješiti prije razvoja.