Gå til indholdet

Skift API-version med overblik over dataflowet

Ved et API-skift skal kaldende systemer, databetydning og svar passe sammen. Et konkret testtilfælde gør overgangen kontrollerbar.

Tobias Krüger2 min. læsetid
Metaladapter med stik ved siden af to stikmoduler mærket v1 og v2 med samme blå datasymbol.

Planlæg skiftet af en programmeringsgrænseflade (API) ud fra de berørte dataflow. Det nye endepunkt er kun en del af overgangen: Felter, rettigheder og fortolkning af svar skal også passe til det kaldende system.

Registrér de berørte kaldende systemer

I en fiktiv virksomhed sender en kundeportal og en natlig import ordrer til samme API. Hvis kun portalen flyttes, efterlades det andet kaldende system. Noter for hvert system, hvilke funktioner det bruger, og hvem der kan gennemføre overgangen. Brug den faktiske udbyders oplysninger om ændringer og lukning; et versionsnummer fastlægger ikke en almengyldig migrationsfrist.

Google AIP-180 skelner mellem kompatibilitet for kildekode, overførsel og betydning. Retningslinjen hjælper med at vurdere ændringer; den garanterer ikke adfærden for et vilkårligt eksternt API.

Beskriv ændringen med et gennemarbejdet eksempel

I vores eksempel indeholder den gamle anmodning tekst i feltet delivery_note. Den nye version forventer teksten under delivery_note.text. Begge skal overføre samme leveringsanvisning, »Tor B«. Det er derfor ikke nok at udskifte en URL eller oprette forbindelse for at gennemføre overgangen.

Kontrolspørgsmål

Aftale i eksemplet

Hvad skal bevares?

Leveringsanvisning Tor B på den rigtige ordre

Hvad ændres teknisk?

Tekstfeltet flyttes ind i en indlejret struktur

Hvad tæller som succes?

Målordren indeholder anvisningen uændret

Hvad sker der, når teksten mangler?

Opret ordren uden leveringsanvisning som hidtil

Kontroller også, hvordan fejl og stadig igangværende behandling meldes tilbage. En anden svarstruktur kan påvirke det kaldende system, selv om anmodningen fortsat accepteres.

Sammenlign gammelt og nyt under samme betingelser

Forbered en normal ordre og et tilfælde uden leveringsanvisning i et egnet testmiljø. Sammenlign de gemte måldata og den synlige tilbagemelding. Afklar også, om de anvendte adgangsrettigheder dækker begge versioner. Til denne sammenligning bør virkelige ordrer ikke sendes ad to produktionsveje.

Afstem skiftet med åbne handlinger

Fastlæg, fra hvilket punkt nye anmodninger bruger den nye vej. Allerede sendte, men endnu ubekræftede anmodninger skal kunne knyttes til deres handling, så en gentagelse ikke behandles som en ny ordre. Aftal en tilbagevej for nye indgående anmodninger, og undersøg særskilt, hvad der sker med allerede skrevne data. At stille en URL tilbage gør ikke disse ændringer om.

Den gamle version kan fjernes fra dette dataflow, når alle registrerede kaldende systemer er flyttet, og åbne handlinger er knyttet korrekt. Dokumenter den faktisk kontrollerede tilstand ud over det nye versionsmærke.

Kilder

Skrevet af

  • Tobias KrügerRedaktør for systemintegrationTobias Krüger beskæftiger sig hos ASES med samspillet mellem forskellige softwaresystemer. I sine artikler forklarer han integrationen af ERP, CRM og webshops samt håndteringen af fejl i dataudvekslingen.

Følg ASES

Læs videre

Alle artikler

Snitflader & integration med ASES

ERP, CRM og webshop forbundet ordentligt