API Versioning: Si evoluon një API pa prishur integrimet ekzistuese?

Një API mund të fillojë me një funksion relativisht të thjeshtë: një aplikacion kërkon të dhëna dhe një sistem tjetër ia dërgon.

Me kalimin e kohës, gjërat ndryshojnë. Shtohen fusha të reja, ndryshon struktura e të dhënave, përmirësohen funksionalitetet dhe lindin kërkesa të reja.

Por ka një problem: API-ja mund të ketë ndryshuar, ndërsa sistemet që e përdorin ende jo.

Nëse disa aplikacione, platforma apo shërbime janë të integruara me të njëjtën API, një ndryshim që duket i vogël mund të ndikojë në disa sisteme njëkohësisht.

Pikërisht këtu hyn API Versioning.

Kur një ndryshim i vogël prek disa sisteme

Marrim një shembull të thjeshtë.

Një API kthen informacionin e një klienti me emrin, adresën dhe numrin e kontaktit. Më vonë, struktura duhet të ndryshojë sepse sistemi kërkon një mënyrë tjetër për organizimin e adresave.

Për aplikacionin e ri, kjo mund të jetë një përmirësim. Por një aplikacion ekzistues mund të presë ende strukturën e mëparshme.

Nëse API-ja ndryshohet drejtpërdrejt, integrimi ekzistues mund të mos funksionojë më siç duhet.

Prandaj, në zhvillimin e API-ve nuk mjafton të mendosh vetëm për funksionalitetin e ri. Duhet të mendosh edhe për sistemet që varen nga sjellja aktuale e API-së.

Versioni i ri mund të ekzistojë krahas atij aktual

API Versioning krijon një mënyrë të kontrolluar për të menaxhuar këtë ndryshim.

Në vend që versioni ekzistues të zëvendësohet menjëherë, mund të krijohet një version i ri. Për shembull, sistemet ekzistuese mund të vazhdojnë të përdorin v1, ndërsa integrimet e reja ose ato që janë përditësuar kalojnë në v2.

Kështu, ndryshimi nuk duhet të ndodhë në të gjithë ekosistemin në të njëjtin moment.

Ekipet kanë kohë të përshtatin integrimet, të testojnë versionin e ri dhe të planifikojnë kalimin gradualisht. Versioni i vjetër mund të vazhdojë të mbështetet për një periudhë të përcaktuar dhe të hiqet vetëm pasi sistemet që varen prej tij të jenë gati.

Jo çdo ndryshim kërkon një version të ri

API Versioning nuk do të thotë që çdo përmirësim duhet të krijojë v2, v3 apo v4.

Shumë ndryshime mund të bëhen duke ruajtur backward compatibility, pra pa ndryshuar mënyrën se si sistemet ekzistuese komunikojnë me API-në.

Versioni i ri bëhet i rëndësishëm kur ndryshimi nuk mund të bëhet pa ndryshuar kontratën ekzistuese të API-së.

Kjo është arsyeja pse versionimi nuk është thjesht një çështje emërtimi. Është pjesë e mënyrës se si projektohet dhe menaxhohet evoluimi i një integrimi.

Një API duhet të projektohet edhe për ndryshimin

Për një kompani software, integrimi i mirë nuk nënkupton vetëm lidhjen e dy sistemeve që duhet të komunikojnë sot.

Sistemet do të ndryshojnë. Aplikacionet do të përditësohen. Kërkesat e biznesit do të evoluojnë.

Prandaj, arkitektura duhet të krijojë hapësirë që këto ndryshime të ndodhin pa e kthyer çdo përditësim në problem për sistemet e tjera.

Siç shprehet Ermal Beqiri, themelues i Soft & Solution Group:

“Një API e projektuar mirë duhet të krijojë mundësinë që sistemi të evoluojë, ndërsa integrimet ekzistuese vazhdojnë të funksionojnë dhe kalimi drejt ndryshimeve të reja bëhet në mënyrë të kontrolluar.”

API Versioning nuk ka të bëjë vetëm me menaxhimin e versioneve, por me krijimin e integrimeve që mund të evoluojnë pa cenuar funksionimin e sistemeve ekzistuese.