Platformy / 01

REST API existuje. Chybí integrace.

Dokumentace existuje, testovací request funguje. V běžném provozu přesto chybějí data nebo vznikají duplicitní záznamy. DataSource propojí vaše REST API s konkrétním obchodním procesem a plánuje i případ, kdy odpověď nepřijde.

HTTP · RESTOAuth · API KeysPagination · Retry

Výchozí stav

Úspěšný request je teprve začátek.

Portál má převzít zákazníky z ERP. Systémy používají různá ID a povinná pole. ERP vrací výsledky po stránkách, portál omezuje zápisy. Ruční export tyto rozdíly zakrývá, ale neřeší je.

Před implementací prověříme podporovanou verzi API, objem dat, požadovanou aktuálnost a cílový kontrakt. OpenAPI dokumentace pomáhá; skutečné anonymizované odpovědi a chybové zprávy jsou stejně důležité.

Co zajišťuje DataSource

Datový kontrakt, přístup a obnovení běhu.

Datový kontrakt

Dohoda zdrojových a cílových polí, identit, datových typů a povinných hodnot. Chybějící hodnoty a změny schématu mají definovaná pravidla.

Přístup a přenos

Implementace autentizace, rozsahu oprávnění a obnovování tokenů podle API. Zohlednění stránkování, časových limitů a pořadí závislých objektů.

Obnovení běhu

Evidence stavu přenosu a externích ID tak, aby přerušené běhy mohly pokračovat. Nejasnou odpověď zápisu nejprve porovnáme, než znovu zapisujeme.

Technický scénář / ilustrativní příklad

Porovnání zákazníků bez duplicitního vytváření.

Příklad ukazuje navržený cílový kontrakt. Externí zákaznické ID je obchodní klíč. Upsert a mechanismy idempotence musí podporovat cílové API nebo je musí zajistit integrace.

Vzorová data a navržená pravidla. Konkrétní rozhraní a obchodní pravidla se prověří pro váš projekt.

Návrh / request do cílového systému
PUT /customers/004218
Content-Type: application/json

{
  "externalId": "004218",
  "name": "Beispiel GmbH",
  "countryCode": "AT"
}

Ošetření chyb, bezpečnost a provoz

Správné vyhodnocení HTTP chyb.

01

Rate limity

Při HTTP 429 dodržet pravidla API a případně Retry-After. Naplánovat omezené opakování s backoffem; trvalé validační chyby potřebují opravu.

02

Konflikty změn

Používat ETagy nebo verzovací pole, pokud jsou podporované. Záznam mezitím změněný nesmí být přepsán starým stavem.

03

Provoz

Dokumentovat korelační ID, čítače a kategorie chyb. Tokeny a úplné payloady s osobními údaji nepatří do obecných provozních logů.

Odborné otázky

Detaily důležité před implementací.

HTTP · REST · OAuth · API Keys · Pagination · Retry

Umí každé API upsert?

Ne. Některá nabízejí pouze oddělené create a update endpointy. Integrace pak potřebuje spolehlivé přiřazení a postup pro nejasné výsledky.

Potřebujeme reálný čas?

Záleží na obchodním procesu. Polling může stačit; webhooky dávají smysl, pokud zdroj spolehlivě oznamuje změny. Porovnání zůstává užitečné pro přehlédnuté události.

Co se stane při nové verzi API?

V testovacím prostředí ověříme kontrakty a reprezentativní chybové scénáře. Termíny ukončení podpory, přechod a postup návratu dohodneme před změnou v produkci.

Pro technické vyjasnění

Začít vaším konkrétním procesem.

Připravte API dokumentaci, verzi, anonymizované příklady, požadovaný směr a aktuálnost. Pomohou známé limity a určení, který systém spravuje která pole.

V prvním rozhovoru vyjasníme dostupné přístupy, odpovědnost za data a omezený první datový tok. Poté dohodneme rozsah, odpovědnosti a podmínky.

Poptávka projektu

Která API mají spolupracovat?

Stručně popište současný proces a požadovaný výsledek.

    Všechna pole jsou povinná. Vaše údaje používáme ke zpracování poptávky. Ochrana osobních údajů

    První krok ke správnému propojení.

    Dotaz nám můžete poslat i v češtině; můžeme jej přeložit. Běžná podpora komunikuje v němčině a angličtině.

    Související úlohy

    Další propojení v kontextu.

    Integrace procesů

    Spolehlivě zpracovat webhooky

    Přijde událost a má vyvolat akci v dalším systému. Opakované doručení, zpoždění nebo výpadek cílového API z toho dělají provozní proces. Vyvineme jej s jednoznačnými událostmi a ověřitelnými účinky.

    Datové procesy

    Transformace dat JSON / XML

    Data jsou technicky čitelná, a přesto odmítaná. Názvy polí, typy nebo struktury neodpovídají cílové aplikaci. Vytváříme dohledatelný mapping, který řeší i prázdné hodnoty, zvláštní případy a změny zdrojového formátu.

    Datové procesy

    Synchronizovat data mezi systémy

    Zákazník se změní v CRM i ERP. Který stav platí? Synchronizaci stavíme na obchodních odpovědnostech a stabilních identitách, aby pravidelné přenosy nevytvářely skryté konflikty dat.

    Technické reference

    Oficiální dokumentace, ověřeno 6. října 2026. Vhodnost závisí na konkrétní instalaci.