API inteqrasiyası iki proqramın razılaşdırılmış qayda ilə məlumat və əməliyyat mübadiləsi etməsidir. İstifadəçi bir kartı dəyişir, başqa sistemdə onunla əlaqəli qeyd yaranır; yaxud sayt sifarişi daxili proqrama ötürür. Görünən nəticə sadə olsa da, əlaqənin qaydaları əvvəlcədən müəyyən edilməlidir.
API hazırlanması və inteqrasiyası üçün əsas sual «bağlana bilərmi?» ilə bitmir. Hansı məlumatın hansı sistemdə əsas olduğu, səhv zamanı kimin tədbir görəcəyi və təkrar sorğunun nəticəsi də işin hissəsidir.
Məlumatın əsas mənbəyini seçin
Bir müştərinin telefonunu hər iki proqramda dəyişmək mümkündürsə, son nəticəni hansı qayda müəyyən edəcək? Son dəyişiklik, təsdiqlənmiş dəyişiklik və əsas sistemin məlumatı fərqli qərarlardır. «İki tərəfli sinxronizasiya» ifadəsi bu mübahisəni öz-özünə həll etmir.
İzahlı nümunə: onlayn mağaza sifarişi biznes proqramına göndərir, anbar proqramı isə mövcudluq məlumatı verir. Bu şərti axında sifarişə və stoka görə əsas mənbələr fərqlidir. Hər sahənin sahibi yazılmalıdır; əks halda gecikmiş cavab yeni məlumatın üzərinə köhnəsini yaza bilər.
Bir əməliyyatın sərhədini müəyyən edin
Sifariş yaratmaq tək sorğu kimi görünsə də, müştəri, məhsul və ünvan məlumatını da əhatə edə bilər. Qarşı tərəf yalnız bir hissəni qəbul etdikdə nə baş verəcəyi razılaşdırılmalıdır. Uğurlu HTTP cavabı biznesin bütün işinin tamamlandığını avtomatik bildirmir.
- Göndəriləcək sahələr və onların mənası.
- Məcburi və boş qala bilən dəyərlər.
- Mənbə ilə təyinat identifikatorlarının uyğunluğu.
- Tarix, ölçü vahidi və valyuta formatı.
- Əməliyyatın tamamlandığını göstərən cavab.
Giriş və səlahiyyət
İnteqrasiya üçün verilən açar yalnız lazım olan əməliyyatlara giriş verməlidir. Müştərinin və ya tərəfdaşın hesabı ilə bütün administrator imkanlarını paylaşmaq rahat görünsə də, artıq səlahiyyət yaradır. Açarın dəyişdirilməsi və bağlanması qaydası da olmalıdır.
OWASP REST təhlükəsizliyi bələdçisi HTTPS, giriş nəzarəti və daxil olan məlumatın yoxlanmasına diqqət yetirir. Layihədə bu texniki nəzarət biznesin müəyyən etdiyi rol və icazə modelinə uyğun qurulmalıdır.
Bağlantı kəsiləndə nə olur?
Şəbəkədə sorğu göndərilib, amma cavab gəlməyə bilər. Bu halda əməliyyatın qarşı tərəfdə baş verib-vermədiyi bilinməyə bilər. İstifadəçiyə yenidən cəhd etməyi deməzdən əvvəl təkrarın eyni işi ikinci dəfə yaradıb-yaratmadığı düşünülməlidir.
Hər əməliyyatı təkrarlamaq eyni dərəcədə təhlükəsiz deyil. Sistem təkrar sorğunu tanımaq üçün razılaşdırılmış identifikator və ya başqa üsul istifadə edə bilər. Texniki həll seçilməzdən əvvəl biznes nəticəsi müəyyən edilməlidir: bir sifariş neçə dəfə yaradıla bilər və hansı vəziyyət ayrıca yoxlamaya göndərilir?
Səhv cavabları istifadəçiyə necə çatdırılır?
«Xəta baş verdi» məlumatı dəstək üçün kifayət etmir. İstifadəçi nəyi düzəldə biləcəyini, əməliyyatın saxlanıb-saxlanmadığını və kiminlə əlaqə quracağını anlamalıdır. Texniki jurnalda isə sirr və şəxsi məlumatı lazımsız yazmadan sorğunun izlənə bilən işarəsi saxlanıla bilər.
İnteqrasiya vəziyyətinin görünməsi də vacibdir. Son yenilənmə tarixi köhnədirsə, qalıq və status cari fakt kimi göstərilməməlidir. Əməliyyatın gözləməsi ilə tam uğursuz olması fərqli vəziyyətlərdir.
Test mühiti və qəbul nümunələri
- Tam və doğru məlumatla uğurlu mübadilə.
- Məcburi sahəsi çatmayan sorğu.
- Yanlış və ya bağlanmış giriş açarı.
- Qarşı tərəfin gecikməsi.
- Eyni sorğunun iki dəfə göndərilməsi.
- Bir hissəsi qəbul edilmiş mürəkkəb əməliyyat.
Bu testlər yalnız bir dəfə ilkin qoşulma üçün deyil, qarşı tərəfin dəyişikliklərində də faydalıdır. Tərəfdaşın xidmət səviyyəsi və limitləri sizin proqramın birbaşa nəzarətində olmaya bilər. Dəstək qaydasında bu sərhəd anlaşılan yazılmalıdır.
Nümunə: eyni hadisə iki dəfə gəlir
Tərəfdaş sistemin əməliyyat bildirişini təkrar göndərdiyini düşünün. Bu şərti vəziyyətdə ikinci bildiriş yeni sifariş kimi qəbul edilməməlidir, əgər biznes hadisəsi eynidirsə. Hansı identifikatorla həmin hadisənin tanınacağı əvvəl razılaşdırılır.
İnteqrasiya jurnalı «cavab gəldi» deməkdən daha çox izah verməlidir: hadisə qəbul edilib, əvvəl işlənib, gözləməyə göndərilib və ya məlumat uyğunsuzluğu var? Bu fərqlər dəstək əməkdaşının nə etməli olduğunu müəyyən edir. Gizli açarlar isə jurnalda açıq göstərilmir.
- Bir hadisəni eyni identifikatorla təkrar göndərin.
- Nəticədə iki sifariş yaranmadığını yoxlayın.
- Fərqli hadisələrin səhvən birləşmədiyini müqayisə edin.
- İstifadəçinin gözləmə vəziyyətini anladığını qiymətləndirin.
Bu nümunədə konkret texniki üsul universal elan edilmir. Məqsəd qəbul meyarını müəyyən etməkdir: təkrar rabitə biznesdə təkrar əməliyyata çevrilməməlidir. Qarşı tərəfin sənədləri buna hansı imkan verdiyini göstərməlidir.
Tez verilən suallar
API varsa, inteqrasiya həmişə mümkündürmü?
Funksiyanın sənəddə olması kifayət deyil. Lazımi hesab icazəsi, şərtlər, test imkanı və məlumat uyğunluğu da tələb oluna bilər.
İnteqrasiyanın qiyməti niyə dəyişir?
Məlumat əlaqələri, səhv ssenariləri və qarşı tərəfin imkanları iş əhatəsinə təsir edir. Bu amillər CRM büdcəsi ilə də əlaqəlidir.
166 Cargo sifariş və sənəd əməliyyatları üzrə portfolio nümunəsidir. Öz əlaqənizi planlaşdırarkən PHP/Laravel API planlaması və sifariş axını mövzularını birlikdə nəzərdən keçirin.
