Valamilyen függés lesz, de általában ez egyirányú, vagyis a kliens függ az API-tól és az API-nak csak arra kell figyelnie, hogy minden változás visszafele kompatibilis vagy megfelelően verziózott legyen. Amit te felvázolsz ott kétirányú függés van, vagyis nem lehet az API-hoz új feature-öket úgy hozzáadni, hogy azt a kliens ne támogassa, vagyis előbb a klienst is fel kell készíteni. Ez még működőképes lehet ha egy csapat dolgozik az adott szoftveren és van pár hetente egy release, de amikor a szoftveren több csapat dolgozik folyamatosan több kontinensen szétszórva és akár több production deployment is van egy nap, akkor ezek a problémák már sokkal nehezebben managelhetőek.
Én se úgy értem, hogy a kliens és az API egymástól független, nyilván az API a kliensek igényét hivatott kiszolgálni és ennek mentén van fejlesztve. Csak azt mondom, hogy az API-nak nem kellene számon tartania, hogy mit és hogyan támogatnak a kliensei, pláne mivel több kliens verzió futhat párhuzamosan.
A példa kedvéért tegyük fel, hogy egy webshopot építünk, aminek a keresőoldalán a találati listát egy ilyen API-val töltjük be. Tehát lesz egy API végpontunk amit hívjunk keresésnek, aminek átadjuk a keresési paramétereket és visszaad egy renderelt listát. Mindegyik termék mellé tesz egy gombot, amivel hozzáadható a termék a kosárhoz. Továbbá lesz egy másik API végpontunk amit hívjuk hozzáadnak, ami megkapja a termék számát és hozzáadja az adott terméket a user sessionben tárolt kosárhoz, valamint visszaad egy üzenetet, hogy a hozzáadás sikerült. A kliens úgy valósítja meg a gomb eseménykezelőjét, hogy meghívja a hozzáad API végpontot az adott termék számával, majd megjeleníti a visszaadott üzenetet.
Miután mindez működik az éles oldalon, kapunk egy olyan feladatot, hogy egyszerre több darabot is hozzá lehessen adni a kosárhoz az adott termékből. Ehhez a gomb mellé kell rakni egy mennyiség mezőt, aminek az alapértelmezett értéke egy, és amit a felhasználó tetszőleges mennyiségre növelhet. Valamint a hozzáad API végpontot is módosítani kell, hogy a termék száma mellett meg lehessen adni a mennyiséget is. Mivel az eseménykezelést a kliens valósítja meg, ezért a klienst is módosítani kell, hogy elküldje a rendelt mennyiséget a hozzáad API-nak. Itt már eleve felmerül a kérdés, hogy a kliens a DOM-on keresztül olvassa ki a mennyiséget, vagy az a mező is kapjon egy eseménykezelőt amin keresztül a kliens kód meg tudja jegyezni, a felhasználó hány darabot rendel. Akárhogy is csináljuk, előbb a klienst kell módosítani, hogy tudja kezelni a találati listában az új mezőt és elküldje a hozzáad API végpontnak, majd ezután deploy-olható az API változtatás.
Azonban mi történik akkor, ha egy felhasználó nyitva hagyott egy tabot pár nappal ezelőttről, és indít egy új keresést? Meg fogja kapni a találati listában a mennyiség mezőt, amivel az ő kliens verziója nem fog tudni mit kezdeni. Ahhoz, hogy ezt a problémát kezeljük, az API-t verziózni kell, és fel kell készíteni a klienst, hogy tudja használni az új API-t. Ekkor előbb az új API verziót kell deploy-olni, ezután lehet frissíteni a klienst, ami már az új API verziót használja. A régi API verziót addig kell támogatni, amíg a régi kliensek végleg eltűnnek (ezt legfeljebb az API monitorozásából deríthetjük ki, meddig érkeznek kérések a régi végpontra).