Page Comparison

...

Riktlinjer för API-versionering i API Manager

Alternativ 1:
Vi lämnar det fritt för API-producenten

Alternativ 2:

En nivå, v1, v2, v3, …

Alternativ 3:

Två nivåer, 1.0, 1.1, 2.0, …

En API-förändring som bryter kontraktet (som gör att APIet inte är bakåtkompatibelt) skall resultera i att man stegar upp huvudversionen (från till exempel 1.0 till 2.0)
En API-förändring som endast lägger till nya resurser eller parametrar till ett API (som gör att APIet är bakåtkompatibelt) skall resultera i att man stegar upp inom huvudversionen (från till exempel 1.0 till 1.1)

Alternativ 4:

Tre nivåer, 1.0.0, 1.0.1, 1.1.0, 2.0.0 …

En API-förändring som bryter kontraktet (som gör att APIet inte är bakåtkompatibelt) skall resultera i att man stegar upp huvudversionen (från till exempel 1.0.0 till 2.0.0)
En API-förändring som endast lägger till nya resurser eller parametrar till ett API (som gör att APIet är bakåtkompatibelt) skall resultera i att man stegar upp inom huvudversionen på nivå två (från till exempel 1.0.0 till 1.1.0)
En API-förändring som ändrar datamängder i ett API (t ex utökar antal val i en ENUM) skall resultera i att man stegar upp inom huvudversionen på nivå tre (från till exempel 1.0.0 till 1.0.1)

Pros and cons

Enklast möjliga för våra API-producenter

Spretigt för våra API-konsumenter

Enkel och rakt på

Ingen indikation på om en versionsuppdatering är bakåtkompatibel eller ej

Tydligare livscykelhantering

Indikation om en versionsuppdatering är bakåtkompatibel eller ej tillgänglig

Något mer administration än i alternativ 2

Klart tydligast livscykelhantering

Indikation om en versionsuppdatering är bakåtkompatibel eller ej tillgänglig

Mer administration än i alternativ 3

Omröstning

Per Persson - inte särskilt betungande, men ger ändå bra koll på livscykeln.

Action items