| Info |
|---|
Add your comments directly to the page. Include links to any relevant research, data, or feedback. |
Bakgrund
På API-design säger vi “APIer skall versionshanteras“.
...
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 | |
|---|
Action items
Outcome