Rasprava „EDI vs API“ je u zadnjih nekoliko godina dobila ton religijskog spora — kao da je riječ o izboru između starog i novog svijeta. U praksi, ozbiljne B2B arhitekture koriste oboje. EDI i API rješavaju različite probleme i komplementarni su, ne suparnici.
U ovom članku objašnjavamo razliku, gdje koji ima prednost, kako se kombiniraju u modernoj hibridnoj arhitekturi i kako REDOK platforma podržava oba pristupa kroz jedan ugovor i jedan operativni nadzor.
EDI — „dokumenti se kreću“
EDI je orijentiran na dokument. Tipičan tijek: jedan strukturirani dokument (UBL račun, EDIFACT ORDERS) napušta vaš ERP, prelazi kroz pristupnik, dolazi u partnerov ERP. Komunikacija je asinkrona — vi pošaljete dokument i nastavljate s drugim poslom; potvrda primitka dolazi minute ili sate kasnije. Volumen tipično: tisuće do stotine tisuća dokumenata dnevno u srednje-velikim okruženjima.
EDI je zlatni standard za high-volume batch tijekove: računi, narudžbenice, otpremnice. Tu su asinkroni, garantirana dostava, pravna valjanost i revizijski trag ključni. EDI dokumenti su „dokument zapisa“ — ono što stoji u arhivi 11 godina i ono što prikažete reviziji.
API — „pristup podacima“
API je orijentiran na podatak. Tipičan tijek: jedan poziv (HTTP GET, REST endpoint) traži određeni podatak (status narudžbe, dostupne zalihe artikla, najnoviji cjenik). Odgovor stiže u milisekundama. Volumen može biti vrlo visok (deseci tisuća poziva u sat), ali svaki poziv je „lagan“ — bez strukturirane dokumentacije, bez arhive.
API je idealan za real-time use case-ove: provjera statusa pošiljke, lookup partnera, upit dostupnih zaliha, sync master podataka. Pravna valjanost i arhivski sloj nisu tu ključni — to je live operativni sloj.
Komplementarnost u modernoj arhitekturi
Tipičan hibridni paterijar izgleda ovako: EDI nosi dokument zapisa (račun, narudžbenica, otpremnica) — to je pravno valjano, arhivirano i čeka u redu za batch obradu. Paralelno, API se koristi za sve „live“ pozive — kupac kroz portal vidi status narudžbe (API GET), provjerava dostupnost robe (API GET), sinkronizira novi cjenik (API PUT/POST).
Drugi čest pattern: EDI za inicijalno slanje dokumenta, API za follow-up. Račun se šalje kao Peppol BIS dokument (EDI), ali partner kroz API može dobiti status („primljen“, „validiran“, „odobren“, „plaćen“) — bez slanja dodatnih EDI poruka za svaki update statusa.
REDOK podrška za oba pristupa
- EDI strana: UBL 2.1, EDIFACT D96A, Peppol BIS Billing 3.0, ANSI X12 — preko sFTP, AS2, AS4 i file-drop.
- API strana: REST/JSON API s OAuth 2.0 autentikacijom — endpoint-ovi za status dokumenata, partner lookup, master data sync, archive retrieval.
- Webhook strana: REDOK može pozvati vaš endpoint kad se dogode određeni eventi (dokument primljen, validacija failed, archive uploaded).
- Jedinstven operativni nadzor: i EDI i API promet u istom dashboardu, isti log-ovi, isti SLA.
Kada birati što
Pravilo iskustva: ako je odgovor na pitanje „treba li ovaj dokument biti u arhivi 11 godina i imati pravnu valjanost?“ DA → EDI. Ako je DA na pitanje „treba li ovaj odgovor stići u istoj sekundi?“ → API. Ako je oba DA — onda hibrid, gdje EDI nosi dokument a API daje live status.
Sažetak
API i EDI nisu suparnici — to su komplementarni alati. EDI rješava high-volume, asinkrono i pravno valjano. API rješava real-time, lagano i operativno. Najbolja arhitektura kombinira oboje, ne odabire jedno na štetu drugog.
REDOK tim radi arhitekturni pregled u kojem mapiramo gdje EDI ima prednost, gdje API ima prednost i gdje hibrid daje najveću vrijednost. Javite se preko kontakt forme.