Göndəriş izləmə API-sində mütləq olmalı 10 xüsusiyyət (Alıcının yoxlama siyahısı)
Göndəriş izləmə API-si alarkən idarə panellərini və ya marketinq iddialarını qiymətləndirməzdən əvvəl etibarlı izləmə hadisələrinə, geniş daşıyıcı əhatəsinə, aydın sənədləşdirməyə, proqnozlaşdırılan xəta emalına və inteqrasiya nəzarətlərinə üstünlük verin. Düzgün API komandanıza daşıyıcı yeniləmələrini dəqiq müştəri bildirişlərinə, əməliyyat iş axınlarına və dəstək cavablarına çevirməyə kömək etməlidir; bunun üçün daimi əl ilə düzəliş tələb edən ikinci bir sistem yaratmamalıdır.
Bu yoxlama siyahısı tətbiq, sifariş idarəetmə sistemi, yardım masası və ya müştəri portalı üçün izləmə API-sini qiymətləndirən məhsul sahibləri, mühəndislik komandaları, logistika menecerləri və e-ticarət operatorları üçün hazırlanıb. Ondan təchizatçıların araşdırılması, texniki nəzərdən keçirmə və konsepsiyanın sübutu mərhələlərində istifadə edin. Təchizatçı bütün tətbiq detalları açıq şəkildə təqdim etmədən müəyyən imkanları reklam edə bilər; buna görə öz göndəriş çeşidinizə və xidmət səviyyəsi tələblərinizə təsir edən maddələri təsdiqləyin.
1. Geniş və uyğun daşıyıcı əhatəsi
Daşıyıcı əhatəsi başlanğıc nöqtəsidir, lakin çox sayda daşıyıcının olması kifayət deyil. Əsas sual API-nin biznesinizin istifadə etdiyi daşıyıcıları, poçt operatorlarını, yükdaşıma təminatçılarını və regional çatdırılma xidmətlərini izləyə bilib-bilməməsidir.
Təchizatçılardan aktual daşıyıcı kataloqu istəyin və onu real göndəriş nümunələri ilə müqayisə edin. Sizin üçün əhəmiyyətli olan ölkələri, xidmət növlərini və izləmə nömrəsi formatlarını nəzərdən keçirin. Daşıyıcı siyahıda göstərilə bilər, lakin yalnız müəyyən xidmətlər, istiqamətlər və ya hadisə növləri dəstəklənə bilər. API-nin poçt ötürmələrini, son mərhələ tərəfdaşlarını və bir neçə logistika təminatçısı arasında hərəkət edən göndərişləri necə idarə etdiyini də soruşmalısınız.
Təchizatçı metodologiyasını izah etmədiyi halda, satınalma qərarını yalnız bir əhatə faizinə əsaslandırmayın. Sizin faktiki marşrutlarınız üzrə əhatə daha geniş ümumi göstəricidən dəyərlidir. Nəzərdən keçirməyə daxili, sərhədlərarası, qaytarılan, əvəzedici göndərişləri və daha az istifadə olunan istiqamətləri daxil edin.
2. Sabit göndəriş izləmə modeli
Müxtəlif daşıyıcılar oxşar mərhələlər üçün fərqli terminlərdən və hadisə strukturlarından istifadə edirlər. Biri bağlamanı göndərilmiş, digəri qəbul edilmiş, başqası isə çeşidləmə məntəqəsindən keçən kimi bildirə bilər. Faydalı izləmə API-si bu yeniləmələri tətbiqinizin ardıcıl şəkildə şərh edə biləcəyi bir modeldə normallaşdırmalı, lazım olduqda isə orijinal daşıyıcı mesajını saxlamalıdır.
API-nin sabit göndəriş identifikatoru, izləmə nömrəsi, daşıyıcı məlumatı, status, hadisə vaxtı, məkan və təsviri mesaj təqdim edib-etmədiyini yoxlayın. Hadisələrin sıralanıb-sıralanmadığını, təkrarlanan hadisələrin baş verə bilib-bilmədiyini və düzəlişlərin və ya gecikmiş hadisələrin necə göstərildiyini müəyyənləşdirin.
Komandanız ilk skanı hələ almamış, hərəkətdə olan, gecikmiş, götürülməyə hazır və çatdırılmış göndərişləri bir-birindən ayıra bilməlidir. Müştəri mesajlarını az sayda qeyri-müəyyən etiket üzərində qurmaqdan çəkinin.
3. Real vaxt və ya hadisə əsaslı bildirişlər
Yalnız sorğulama lazımsız trafik və müştəriyə göstərilən yeniləmələrdə gecikmə yarada bilər. Bir çox tətbiq üçün vebhuk və ya digər hadisə əsaslı bildirişlər mühüm satınalma tələbidir. Bunlar sisteminizə eyni statusu təkrar-təkrar soruşmaq əvəzinə, əhəmiyyətli göndəriş hadisəsi əlçatan olduqda reaksiya verməyə imkan yaradır.
Bildirişlərin həqiqətən ehtiyac duyduğunuz hadisələr üçün, məsələn, tranzitdə, çatdırılma cəhdi, çatdırılma istisnası və çatdırılıb statusları üçün əlçatan olduğunu təsdiqləyin. Təchizatçının sorğuları necə autentifikasiya etdiyini, faydalı yükü necə imzaladığını, uğursuz çatdırılmaları necə təkrar etdiyini və sizin tərəfinizdə müvəqqəti fasilələri necə idarə etdiyini soruşun.
Bildirişləri qəbul edən son nöqtəniz idempotent olmalıdır. Praktik olaraq bu o deməkdir ki, eyni bildirişin bir dəfədən çox emal edilməsi təkrarlanan e-poçtların göndərilməsinə, dublikat biletlərin yaradılmasına və ya anbar əməliyyatlarının yenidən işə salınmasına səbəb olmur. Həmçinin sisteminizə orijinal hadisə vaxtının, bildiriş vaxtının, yoxsa hər ikisinin lazım olub-olmadığına qərar verin.
4. Aydın API sənədləşdirməsi və nümunələr
Sənədləşdirmə məhsul xüsusiyyətidir. Müqavilə imzalanmazdan əvvəl mühəndis satış əlaqələndiricisindən tam asılı olmadan autentifikasiyanı, sorğu formatlarını, cavab sahələrini, status kodlarını, səhifələməni, vebhuk davranışını və ümumi uğursuzluq hallarını başa düşə bilməlidir.
Komandanızın istifadə etdiyi dillərdə tam nümunələr axtarın. Sənədləşdirmənin tələb olunan və əlavə parametrləri, sahə tiplərini, tarix formatlarını, regional parametrləri, səhv formatlanmış sorğu ilə naməlum göndəriş üçün etibarlı sorğu arasındakı fərqi izah edib-etmədiyini yoxlayın.
Yaxşı sənədləşdirmə versiyalaşdırmanı və dəyişikliklərin idarə edilməsini də izah etməlidir. Sahənin silinməsindən, hadisə dəyərinin dəyişdirilməsindən və ya yeni cavab strukturunun tətbiqindən əvvəl təchizatçının nə qədər bildiriş verdiyini soruşun. Açıq sənəd natamamdırsa, imkanın mövcud olmadığını fərz etmək əvəzinə bunu araşdırılmalı məsələ kimi qeyd edin.
5. Proqnozlaşdırılan autentifikasiya və giriş nəzarətləri
İzləmə API-si müştəri sifarişləri ilə əlaqəli ola bilən əməliyyat məlumatlarını emal edəcək. Buna görə onun təhlükəsizlik modeli arxitekturanıza uyğun olmalıdır. Giriş məlumatlarının necə verildiyini, yeniləndiyini, ləğv edildiyini və inkişaf, sınaq və istehsal mühitləri arasında necə ayrıldığını nəzərdən keçirin.
Xidmətin mühitlərin ayrılmasını, məhdud əhatəli giriş məlumatlarını, server tərəfli autentifikasiyanı və yerləşdirməniz üçün uyğun məhdudiyyətləri dəstəklədiyini təsdiqləyin. Təchizatçı həmin istifadə ssenarisi üçün təhlükəsiz dizaynı açıq şəkildə sənədləşdirməyibsə, şəxsi API giriş məlumatlarını heç vaxt brauzer koduna və ya mobil tətbiqlərə yerləşdirməyin.
Təchizatçının şübhəli trafiki, giriş məlumatlarının ifşasını və hesab səviyyəsində girişi necə idarə etdiyini soruşun. API şəxsi məlumatları və ya müxtəlif bazarlardakı göndəriş detalları emal edəcəksə, təhlükəsizlik şərtləri texniki və hüquq komandalarınız tərəfindən nəzərdən keçirilməlidir.
6. Sürət məhdudiyyətləri, kvotalar və istifadə görünürlüğü
Sürət məhdudiyyətləri həm arxitekturaya, həm də xərclərə təsir edir. Təchizatçı sorğu limitlərini, qısa müddətli artım davranışını, kvota müddətlərini, paralellik məhdudiyyətlərini və limitə çatıldıqda qaytarılan cavabı izah etməlidir. Sənədləşdirmədə bu detallar göstərilmirsə, yazılı təsdiq istəyin.
Faktiki iş axınınız əsasında istifadə modeli qurun. Hər sifarişi bir dəfə izləyən sistemin trafiki aktiv göndərişləri tez-tez yeniləyən, müştərilərə özünəxidmət axtarışı təqdim edən və idxaldan sonra məlumatları geriyə dolduran sistemdən çox fərqli ola bilər. Pik satış dövrlərini, toplu yükləmələri, daşıyıcı gecikmələrini və təkrar sorğu trafikini nəzərə alın.
Faydalı əməliyyat nəzarətlərinə istifadə panelləri, kvota xəbərdarlıqları, sorğu identifikatorları və keşləmə və ya sorğulama intervalları üzrə tövsiyələr daxildir. Limitsiz kimi təqdim olunan planın ədalətli istifadə şərtləri və ya texniki limitləri olmadığını düşünməyin. İstehsala başlamazdan əvvəl əlavə istifadənin və müvəqqəti sürət məhdudlaşdırmasının necə idarə edildiyini soruşun.
7. Güclü xəta emalı və müşahidəolunma
İzləmə sistemləri adi uğursuzluqları idarə etməlidir: etibarsız izləmə nömrələri, dəstəklənməyən daşıyıcılar, daşıyıcının müvəqqəti dayanması, şəbəkə xətaları, dublikat göndərişlər və gecikmiş məlumatlar. Etibarlı API bu halları bir-birindən ayırmağa imkan verir.
HTTP status kodlarını, xəta obyektlərini, xəta mesajlarını və sorğu identifikatorlarını nəzərdən keçirin. Tətbiqiniz istifadəçi məlumatlarını düzəltmək, daha sonra yenidən cəhd etmək, problemi dəstəyə yönləndirmək və ya göndərişi ilk skanı gözləyən kimi qeyd etmək barədə qərar verə bilməlidir. “Sorğu uğursuz oldu” kimi ümumi xəta avtomatlaşdırılmış əməliyyatlar üçün kifayət deyil.
Təchizatçının statusla bağlı kommunikasiya və dəstək prosesini də yoxlayın. API status səhifəsi faydalı ola bilər, lakin tətbiq səviyyəsində jurnal qeydini əvəz etmir. Saxlama və məxfilik tələblərinizə uyğun şəkildə sorğu vaxtını, təchizatçı cavabını, izləmə identifikatorunu və daxili korrelyasiya ID-sini saxlayın.
8. Məlumatların aktuallığı və hadisə tarixçəsi
İzləmə məlumatları yalnız istifadəçilər onun nə qədər aktual olduğunu başa düşdükdə faydalıdır. Xidmətin yeniləmələri nə qədər tez-tez əldə etdiyini, müxtəlif daşıyıcıların fərqli intervallarda yenilənib-yenilənmədiyini və API-nin hadisənin qəbul edildiyini və ya sonuncu dəfə yoxlanıldığını necə göstərdiyini soruşun.
Cavabın tam hadisə tarixçəsini, yoxsa yalnız son vəziyyəti ehtiva etdiyini nəzərdən keçirin. Tam tarixçə müştəri dəstəyi, çatdırılma araşdırmaları, iddia prosesləri və analitika üçün dəyərlidir. O, həmçinin dublikat, yenidən sıralanmış və ya düzəldilmiş hadisələri üzə çıxara bilər; buna görə məlumat modeliniz hər yeniləmənin tamamilə yeni mərhələ olduğunu fərz etməməlidir.
Konsepsiyanın sübutu zamanı API cavablarını nümunəvi göndərişlər üçün daşıyıcı səhifələri və ya daşıyıcının təqdim etdiyi məlumatlarla müqayisə edin. Hər mənbənin tam olaraq eyni anda yenilənməsini gözləməyin. Məqsəd normal gecikməni və məlumatların natamam ola biləcəyi şərtləri anlamaqdır.
9. Beynəlmiləlləşdirmə və sərhədlərarası kontekst
Sərhədlərarası göndərişlər tərcümə edilmiş status etiketindən daha çoxunu tələb edir. Alıcılar hadisələri üstünlük verdikləri dildə və saat qurşağında başa düşə bilməli, əməliyyat komandaları isə araşdırma üçün orijinal daşıyıcı ifadəsinə ehtiyac duya bilər.
Lokallaşdırılmış mesajlar, təyinat və mənşə məlumatları, saat qurşağının idarə edilməsi, ölkə kodları və beynəlxalq izləmə nömrələri üzrə dəstəyi yoxlayın. Gömrüklə bağlı hadisələrin adi tranzit hadisələrindən ayrıca göstərilib-göstərilmədiyini müəyyənləşdirin. Rüsumlar, vergilər və ya rəsmiləşdirmə məlumatları API-nin əhatə dairəsindən kənardadırsa, məhsul dizaynınızda bu sərhədi aydın göstərin.
Daşıyıcı dəyişən və ya bir neçə ölkədən keçən göndərişləri sınaqdan keçirin. Daxili bağlama üçün işləyən status modeli göndəriş gömrük emalını gözlədikdə və ya yerli çatdırılma tərəfdaşına təhvil verildikdə yanıltıcı ola bilər.
10. İnteqrasiyaya uyğunluq və kommersiya şəffaflığı
Son xüsusiyyət tək bir son nöqtə deyil. Bu, API-nin artıq idarə etdiyiniz sistem və proseslərə uyğunluğudur. İnteqrasiyanı sifariş idarəetmə sisteminiz, anbar alətləriniz, e-ticarət platformanız, müştəri xidməti platformanız, analitika stekiniz və bildiriş təminatçınızla əlaqələndirin.
Toplu izləmə, uyğun olduqda göndəriş yaratma və ya qeydiyyatı, vebhukları, sınağı, ixracı və məlumatların saxlanmasını praktiki şəkildə dəstəkləyən imkanları axtarın. Nəzərdən keçirdiyiniz plana hansı funksiyaların daxil olduğunu təsdiqləyin; sənədləşdirilmiş hər son nöqtənin hər bir müştəri üçün əlçatan olduğunu düşünməyin.
Qiymətləndirmə gözlənilən sorğu həcminizə, aktiv göndərişlərə, daşıyıcı çeşidinə, mühitlərə, dəstək tələblərinə və artım modelinə əsasən aparılmalıdır. Hesablamanın sorğulara, izlənən göndərişlərə, hadisələrə və ya başqa vahidə əsaslandığını soruşun. Minimum öhdəliklər, əlavə istifadə, ləğv və plan limitlərində dəyişikliklərlə bağlı yazılı cavablar əldə edin. Qiymət açıq şəkildə göstərilmirsə, onu təxmin etmək əvəzinə birbaşa təsdiqlənməli məsələ kimi qeyd edin.
Praktik izləmə API-si qiymətləndirməsini necə aparmalı
- Göndəriş kütləsini müəyyənləşdirin. Emal etməyi gözlədiyiniz daşıyıcıları, ölkələri, xidmətləri, izləmə nömrəsi formatlarını və göndəriş həcmlərini sadalayın.
- Qəbul meyarlarını yazın. Tətbiqinizin tələb etdiyi statusları, hadisə sahələrini, aktuallıq gözləntilərini, bildiriş davranışını və xəta cavablarını müəyyənləşdirin.
- Real nümunələrdən təhlükəsiz istifadə edin. Çatdırılmış, tranzitdə olan, gecikmiş, qaytarılmış, etibarsız, sərhədlərarası və yeni yaradılmış göndərişləri sınaqdan keçirin. Lazımsız şəxsi məlumatları silin.
- Tam həyat dövrünü sınaqdan keçirin. Sorğular göndərin, hadisələri qəbul edin, uğursuzluqları təkrar sınayın, dublikatları emal edin və daşıyıcı məlumatları gecikdikdə sisteminizin necə davrandığını təsdiqləyin.
- Əməliyyat səylərini ölçün. İnteqrasiya vaxtını, sənədləşdirmə boşluqlarını, dəstək cavabının keyfiyyətini, monitorinq ehtiyaclarını və komandanızın qurmalı olduğu normallaşdırma səviyyəsini qeyd edin.
- Kommersiya şərtlərini təsdiqləyin. Sınaqdan keçirilmiş iş axınını təklif olunan planla uyğunlaşdırın və təsdiqlənməmiş hər limit və ya xüsusiyyət üçün aydınlıq istəyin.
17TRACK qiymətləndirmədə hansı yer tutur
17TRACK xüsusi Tracking API məhsulu təqdim edir və tərtibatçılar üçün API sənədləşdirməsi dərc edir. Bu, tələb daşıyıcıya məxsus inteqrasiyadan çox, bir neçə daşıyıcı üzrə göndəriş görünürlüğüdürsə, onu nəzərdən keçirilməli uyğun seçimə çevirir. Rəsmi API materiallarını öz daşıyıcı siyahınız, nümunə izləmə nömrələriniz, hadisə tələbləriniz və gözlənilən trafikinizlə birlikdə nəzərdən keçirin.
Düzgün satınalma nəticəsi yalnız brend tanınmasına deyil, nəzarətli sınağa əsaslanmalıdır. Biznesiniz üçün əhəmiyyətli daşıyıcıları və funksiyaları yoxlayın, tətbiq olunan hesab şərtlərini təsdiqləyin və qaytarılan məlumatların daxili status modelinizə necə uyğun gəldiyini qiymətləndirin. Eyni yoxlama siyahısı 17TRACK-i digər izləmə API-si təminatçıları ilə müqayisə edərkən də tətbiq olunur.
Alıcının qərar yoxlama siyahısı
- Daşıyıcı kataloqu faktiki göndəriş marşrutlarınıza uyğundurmu?
- API əhəmiyyətli çatdırılma vəziyyətlərini ayıra və daşıyıcı detallarını qoruya bilirmi?
- Vebhuklar, təkrar cəhdlər, autentifikasiya və dublikatların idarə edilməsi sənədləşdirilibmi?
- Komandanız API-ni real göndəriş nümunələri ilə sınaqdan keçirə bilərmi?
- Sürət məhdudiyyətləri, istifadə vahidləri, dəstək şərtləri və plan sərhədləri aydındırmı?
- Uğursuzluqları izləyə və məlumatların aktuallığını müştərilərə izah edə bilərsinizmi?
- API sərhədlərarası və bir neçə daşıyıcılı marşrutları düzgün idarə edirmi?
- Sənədləşdirilmiş miqrasiya və versiyalaşdırma yolu varmı?
Tez-tez verilən suallar
Ən böyük daşıyıcı siyahısına malik API-ni seçməliyəm?
Mütləq deyil. Göndəriş kütlənizdəki daşıyıcıları, istiqamətləri və xidmətləri etibarlı şəkildə əhatə edən təminatçını seçin. Daha kiçik, lakin uyğun əhatə dəsti marşrutlarınıza və ya hadisə tələblərinizə uyğun olmayan daha böyük siyahıdan faydalı ola bilər.
Vebhuklar sorğulamadan daha yaxşıdır?
Onlar müxtəlif problemləri həll edir. Vebhuklar lazımsız sorğulamaları azalda və tətbiqinizə yeniləmələrə tez reaksiya verməyə kömək edə bilər, sorğulama isə ehtiyat və ya dövri uzlaşdırma prosesi təmin edə bilər. Təchizatçının sənədləşdirilmiş davranışından asılı olaraq, möhkəm dizayn nəzarətli uzlaşdırma ilə hadisə bildirişlərindən istifadə edə bilər.
Konsepsiyanın sübutu zamanı nəyi sınaqdan keçirməliyəm?
Ümumi və çətin halları sınaqdan keçirin: yeni izləmə nömrəsi, tranzitdə olan bağlama, çatdırılmış göndəriş, gecikmə, qaytarılma, etibarsız nömrə, sərhədlərarası göndəriş, dublikat bildirişlər və müvəqqəti API xətası. Həm məlumat keyfiyyətini, həm də ondan təhlükəsiz istifadə üçün tələb olunan mühəndislik səylərini ölçün.
İzləmə API-si göndəriş məlumatlarını nə qədər tez-tez yeniləməlidir?
Hər daşıyıcıya və xidmətə tətbiq olunan vahid interval yoxdur. Aktuallığın necə müəyyən edildiyini, göndərişin sonuncu dəfə nə vaxt yoxlanıldığını və daşıyıcı gecikmələrinin cavaba necə təsir etdiyini soruşun. Müştəri gözləntilərini API-nin faktiki təqdim etdiyi məlumat əsasında formalaşdırın.
Yalnız API-nin normallaşdırılmış statusuna etibar edə bilərəm?
Ardıcıl iş axınları üçün normallaşdırılmış statuslardan istifadə edin, lakin mümkün olduqda orijinal hadisə detallarını saxlayın. Daşıyıcı ifadələri, vaxt möhürləri və məkanlar dəstək araşdırmaları, istisnaların idarə edilməsi və mübahisələr üçün mühüm ola bilər.
