API vasitəsilə sifariş yoxlanılarkən «icra olunur» statusunun emalı

API cavabında processing nə deməkdir

processing, in_progress və ya digər ekvivalent vəziyyət o deməkdir ki, təchizatçı sifarişi işə qəbul edib, lakin yekunu qeydə almayıb. Təşviq xidmətləri üçün bu, linkin yoxlanılması, növbə gözləməsi, tapşırığın işə salınması və ya sifariş edilmiş həcmin tədricən verilməsi ola bilər.

Processing uğurlu icranı təsdiqləmir və xəta demək deyil. Ondan sonra sifariş completed, partial, canceled və ya failed vəziyyətinə keçə bilər. Təchizatçı aralıq status qaytardıqca, eyni link və eyni həcm üçün təkrar müraciət yaratmayın.

processing statusu ilə HTTP 200 API-nin uğurlu cavabı deməkdir, sifarişin uğurlu tamamlanması deyil. Bu hadisələr ayrıca saxlanmalı və emal edilməlidir.

Sifarişin yoxlanılması üçün hansı məlumatlar lazımdır

Polling üçün təchizatçının yaratma zamanı qaytardığı xarici sifariş ID-si lazımdır. Onu daxili ID, ilkin həcm, xidmət parametrləri, link, yaradılma vaxtı və ilkin API cavabı ilə birlikdə saxlayın. Kanal adı, link və ya həcmə görə sifariş axtarmaq etibarsızdır: bu dəyərlər bir neçə müraciətdə üst-üstə düşə bilər.

Əgər yaradıldıqdan sonra taym-aut gəlibsə, müraciəti avtomatik təkrar göndərməyin. Təchizatçı sorğunu qəbul edə bilər, cavab isə yolda itə bilər. Əvvəlcə sənədləşmədə varsa, sifariş axtarma metodundan istifadə edin, ya da halı yoxlamaya verin.

Yalnız cari statusun saxlanmasının çatışmazlığı ondan ibarətdir ki, mübahisə zamanı sifarişin nə vaxt processing-ə keçdiyini, tərəqqi olub-olmadığını və əvvəllər hansı cavabların gəldiyini bərpa etmək mümkün deyil.

curl vasitəsilə status sorğusu nümunəsi

Dəqiq ünvanı, avtorizasiya metodunu və sahə adlarını təchizatçının sənədləşməsindən götürün. Aşağıda şablon göstərilib: bucaqlı mötərizədəki dəyərləri konkret API-nin məlumatları ilə əvəz etmək lazımdır.

Bir sifariş üçün GET sorğusu

curl -X GET "https:///orders//status" \

-H "Authorization: Bearer " \

-H "Accept: application/json"

Cavab nümunəsi:

{

"order_id": "",

"status": "processing",

"completed_quantity": 250,

"remains": 750,

"updated_at": "значение_времени"

}

completed_quantity və remains sahələri yalnız struktur nümunəsi kimi verilib. Təchizatçı progress, start_count, balance və ya digər adlardan istifadə edə bilər. GET yanaşmasının çatışmazlığı ondan ibarətdir ki, bəzi API-lər status yoxlamasını yalnız POST vasitəsilə qəbul edir.

POST sorğusu və toplu yoxlama nümunəsi

Bir sifarişin statusu üçün POST sorğusu

curl -X POST "https:///orders/status" \

-H "Authorization: Bearer " \

-H "Content-Type: application/json" \

-d '{"order_id":""}'

API açarını URL sətrində ötürməyin. Sorğu ünvanları proksi jurnallarına, analitika sistemlərinə, brauzer tarixçəsinə və texniki loqlara düşür. POST-un çatışmazlığı ondan ibarətdir ki, onu ünvan sətri vasitəsilə əl ilə yoxlamaq daha çətindir, lakin bu, sirri URL-ə köçürmək üçün səbəb deyil.

Aktiv sifarişlər üçün toplu sorğu

Əgər API toplu yoxlamanı dəstəkləyirsə, bir neçə ID-ni bir sorğu ilə göndərin:

curl -X POST "https:///orders/statuses" \

-H "Authorization: Bearer " \

-H "Content-Type: application/json" \

-d '{"order_ids":["",""]}'

Cavabı massivdəki elementin mövqeyinə görə deyil, xarici ID-yə görə daxili sifarişlə uyğunlaşdırın. Toplu yoxlamanın çatışmazlığı: təchizatçı bütün sifarişləri qaytarmaya, siyahının ölçüsünü məhdudlaşdıra və ya yalnız bir ID üçün xəta bildirə bilər.

processing üçün polling-i necə təyin etmək olar

İlk processing cavabından sonra növbəti yoxlamanı növbəyə qoyun. İntervalı API sənədləşməsinə, tezlik məhdudiyyətlərinə və xidmətin xarakterinə görə seçin. Statusun sürətlə dəyişdiyi tapşırıqlar üçün əvvəldə daha tez-tez yoxlama məqbuldur. Tədricən təşviq üçün daimi qısa sorğular adətən yeni məlumat vermir.

Praktik sxem — eyni processing cavablarından sonra fasiləni artırmaqdır. İlk yoxlama başlanğıc gecikməsindən sonra gedir, sonra interval müəyyən edilmiş maksimuma qədər artır. Əgər API tərəqqi və ya yeni yenilənmə vaxtı qaytarırsa, hesablamanı bu dəyişiklikdən başlamaq olar.

• Sifariş yaradıldıqdan sonra statusu dərhal çox dəfə ardıcıl yoxlamayın: xidmətə növbəyə qoyulmaq üçün vaxt lazım ola bilər.
• Təkrarlanan processing zamanı sorğular arasındakı intervalı artırın, daimi tezliyi saxlamayın.
• Sifarişlərin API-yə eyni vaxtda sorğu göndərməməsi üçün tapşırıqların işə salınma vaxtına kiçik təsadüfi sapma əlavə edin.
• Əgər təchizatçı Retry-After və ya bənzər tövsiyə ötürürsə, onu prioritet kimi istifadə edin.
• Vebhukları olan sifarişlər üçün nəzarət polling-i saxlayın: bildiriş çatmaya bilər.

Seyrək polling-in çatışmazlığı — interfeys faktiki tamamlanmadan sonra köhnə status göstərə bilər. Çox tez-tez polling-in çatışmazlığı — API limitlərinə dirənmək, 429 almaq və artıq yük yaratmaq riski.

processing nəzarəti üçün hansı vaxtları saxlamaq lazımdır

Adi icranı donmadan ayırmaq üçün yalnız cari status kifayət etmir. Hər aktiv sifariş üçün yaradılma vaxtını, processing-in ilk alınmasını, son uğurlu API cavabını, xarici statusun son dəyişməsini və tərəqqinin son dəyişməsini saxlayın.

Həmçinin ilkin həcmi, təsdiqlənmiş icra olunmuş həcmi, qalığı və təchizatçının orijinal statusunu saxlamaq faydalıdır. Əgər API tərəqqi vermirsə, bu, sifarişi donmuş hesab etmək üçün səbəb deyil: son cavabın vaxtına və xidmətin şərtlərində göstərilibsə, gözlənilən emal müddətinə əsaslanın.

Maksimum gözləmə vaxtını bütün xidmətlər üçün bir rəqəmlə təyin etmək olmaz. Təchizatçının konkret xidmət üçün göstərdiyi müddətdən istifadə edin, növbə və məlumatların yenilənməsi üçün daxili ehtiyatla. Əgər müddət göstərilməyibsə, hər xidmət kateqoriyası üçün ayrıca qayda təyin edin və onu faktiki emal tarixçəsinə əsasən yenidən nəzərdən keçirin.

processing dəyişmirsə nə etməli

Uzun sürən processing xətanı sübut etmir. Əvvəlcə uğurlu API cavablarının gəlib-gəlmədiyini, completed_quantity və ya remains-in dəyişib-dəyişmədiyini, vebhukların olub-olmadığını və xidmət qaydalarının dəyişib-dəyişmədiyini yoxlayın. Görünən artımın olmaması platformanın statistikasının gecikməsi və ya təchizatçının tərəqqini yalnız finalda yeniləməsi ilə bağlı ola bilər.

Daxili gözləmə müddəti aşıldıqda sifarişi avtomatik ləğv etməyin. Növbədənkənar status yoxlaması aparın, nəzərdə tutulubsa, ayrıca metodla məlumat sorğulayın və bildirişlər tarixçəsini yoxlayın. Əgər təchizatçı hələ də processing-i təsdiqləyirsə, sifarişi «yoxlama tələb olunur» daxili vəziyyətinə keçirin, lakin xarici statusu əvəzləmədən saxlayın.

• Son təsdiqlənmiş cavabın vaxtını və bütün API cavabını qeyd edin.
• Əvvəlki sorğudan bəri tərəqqinin dəyişib-dəyişmədiyini yoxlayın.
• Daxili həddə çatdıqdan sonra avtomatik sorğuların tezliyini azaldın.
• Dəstəyə xarici ID, link, xidmət parametrləri, statuslar tarixçəsi və texniki xətaları ötürün.
• Təchizatçının cavabına və ya aydın final statusa qədər qalığı təkrar işə salmayın.

Əl ilə yoxlamanın çatışmazlığı — sifariş dəstəyin diqqətini tələb edir. Lakin avtomatik ləğv və ya dublikat daha təhlükəlidir: icra təchizatçıda davam edə bilər.

Sorğu nasazlığını sifariş statusundan necə ayırmaq olar

Şəbəkə xətası, taym-aut, HTTP 429 və 5xx cavabı sifarişin özünün vəziyyətini bildirmir. Onlar yalnız yeni etibarlı statusun alına bilmədiyini bildirir. Belə vəziyyətdə son təsdiqlənmiş statusu saxlayın, texniki xətanı qeyd edin və yeni yoxlama planlaşdırın.

429 zamanı başlıq ötürülübsə, Retry-After-ı nəzərə alın. Müvəqqəti şəbəkə xətaları və 5xx zamanı cəhdlər arasındakı fasiləni artırın. Avtorizasiya, imza və ya giriş hüquqları xətası zamanı tez-tez retray etməyin: açarı, tokenin etibarlılıq müddətini, IP məhdudiyyətlərini və giriş parametrlərini yoxlamaq lazımdır.

Əgər API HTTP 200 qaytarıbsa, lakin JSON oxunmursa və ya cavabda order_id və status yoxdursa, cavabın gövdəsini tam saxlayın və yoxlamanı səhv kimi qeyd edin. Statusun olmamasını completed, canceled və ya processing ilə əvəz etməyin.

Avtomatik təkrar sorğuları nə vaxt dayandırmaq lazımdır

Polling sonsuz olmamalıdır. Müvəqqəti xətalar üçün texniki təkrar cəhdlərin sayını məhdudlaşdırın və sifarişin processing-də qalma müddətini ayrıca nəzarətdə saxlayın. Retray limiti tükəndikdən sonra yoxlama tapşırığını təhlil növbəsinə keçirin, hər dəqiqə nəticəsiz yeni sorğular yaratmayın.

Status sorğusunun təkrarı adətən təhlükəsizdir, əgər metod yalnız məlumat oxuyursa. Yaratma, ləğv etmə, artırma, yenidən işə salma və qaytarma metodlarını taym-autdan sonra mexaniki təkrarlamaq olmaz. İdempotent açar və ya təchizatçının aydın təsdiqi olmadan belə təkrar sifarişi iki dəfə dəyişə bilər.

Retray məhdudiyyətinin çatışmazlığı ondan ibarətdir ki, yeniləmələrin bir hissəsi əl ilə tapşırığa çevriləcək. Sonsuz retraylar daha pisdir: onlar nasazlığı maskalayır, limitləri sərf edir və jurnalların təhlilini çətinləşdirir.

processing-dən sonra final statusu necə qəbul etmək olar

Gecikmiş polling cavabı və ya köhnə vebhuk səbəbindən completed-dən processing-ə geriyə keçidə yol verməyin. Hər yenilənmədə təchizatçıdan gələn hadisənin vaxtını, varsa, versiyanın sıra nömrəsini və cari daxili vəziyyəti müqayisə edin.

• new və pending processing, canceled və ya failed vəziyyətinə keçə bilər.
• processing completed, partial, canceled və ya failed vəziyyətinə keçə bilər.
• partial-ı avtomatik completed hesab etmək lazım deyil.
• completed, canceled və failed adətən final hesab olunur və avtomatik geriyə qayıdışı bloklayır.
• Naməlum status və ya yol verilməz keçid ayrıca yoxlama tələb edir.

Sərt keçid cədvəlinin də çatışmazlığı var: təchizatçı düzgün yeni vəziyyət əlavə edə bilər. Buna görə orijinal statusu saxlayın və onu daxili təsnifatla üzərinə yazmayın.

partial və sifariş qalığını necə emal etmək olar

Partial o deməkdir ki, ilkin həcmin yalnız bir hissəsi təsdiqlənib. API cavabında faktiki icra olunmuş miqdar, qalıq, səbəb və kompensasiya haqqında məlumat ola bilər. Bu dəyərləri ayrıca saxlayın: sifarişin ilkin həcmini icra olunmuş miqdarla əvəz etmək olmaz.

Final cavab nümunəsi belə görünə bilər:

{

"order_id": "",

"status": "partial",

"completed_quantity": 700,

"remains": 300,

"refund": "значение_или_отсутствие_поля"

}

Əvvəlcə API-nin dəqiq nəyi təsdiqlədiyini müəyyən edin: qaytarma artıq həyata keçirilib, qaytarma yalnız planlaşdırılıb, qalıq ləğv edilib və ya dəstəyə müraciət tələb olunur. Əgər qaytarma haqqında sahə yoxdursa, qalığı avtomatik kompensasiya edilmiş hesab etməyin.

İcra olunmamış hissəni ayrıca qərar olmadan yenidən işə salmayın. Təchizatçı hələ hesablaşmanı tamamlaya bilər, platformanın statistikası gecikmə ilə yenilənə bilər, təkrar müraciət isə dublikat təşviq yarada bilər. Təsdiq gözləmənin çatışmazlığı — qalıq dərhal bağlanmayacaq, lakin artıq sifariş yaranmayacaq.

Vebhuklar nəzarət yoxlamasını əvəz etmir

Vebhuk növbəti polling-i gözləmədən hadisədən dərhal sonra sifariş kartını yeniləməyə imkan verir. Emal edicidə sifarişi xarici ID-yə görə tapın, imzanı və ya sirri yoxlayın, hadisə ID-sini saxlayın və keçidi yalnız yol verilənliyi yoxladıqdan sonra tətbiq edin.

Vebhukun təkrar çatdırılması təhlükəsiz olmalıdır: eyni hadisəni yeni dəyişiklik hesab etmək olmaz. Hadisələr həmçinin sıra ilə gəlməyə bilər, buna görə final sifarişi yalnız gecikmiş processing əsasında geriyə qaytarmayın.

Nəzarət polling-i sabit vebhuklar zamanı belə lazımdır. Vebhukların çatışmazlığı — daha mürəkkəb quraşdırma: əlçatan emal edici, saxta sorğulardan qorunma, deduplikasiya və hadisə jurnalı tələb olunur.

processing və donma zamanı müştəriyə nə göstərmək lazımdır

İnterfeysdə bütün texniki JSON-u çıxarmaq lazım deyil. Processing üçün «sifariş işdədir» vəziyyəti kifayətdir. Əgər API etibarlı tərəqqi ötürübsə, təsdiqlənmiş həcmi ilkin həcmdən ayrı göstərin və onu yekun nəticə kimi təqdim etməyin.

Daxili nəzarət müddətini aşmış sifariş üçün «icranı yoxlayırıq» kimi aydın vəziyyətdən istifadə edin. Təchizatçının cavabı ilə təsdiqlənməyincə ləğv, qaytarma və ya tam tamamlanma haqqında bildirməyin.

Bildirişlər sifarişin qəbulu, final icra, partial, ləğv, xəta və yoxlama zərurəti zamanı faydalıdır. Hər polling-dən sonra mesajlar səs-küy yaradır və müştəriyə müraciətin real vəziyyətini anlamağa kömək etmir.

Emal jurnalında hansı qeydlər lazımdır

Cavablar tarixçəsi donmuş processing-i, itirilmiş vebhuku, qismən icra ilə bağlı mübahisəni və interfeyslə API arasındakı uyğunsuzluğu təhlil etməyə kömək edir. Hər müraciət üçün xarici ID, yenilənmə mənbəyi, sorğu və cavab vaxtı, HTTP kodu, orijinal status, normallaşdırılmış status, tərəqqi, qalıq və texniki xətanın mətnini saxlayın.

Adi loqlara API açarlarını, tokenləri, imzaları və digər sirləri yazmayın. Xam cavablara girişi məhdudlaşdırın: onlarda dəstək interfeysində olmamalı olan məlumatlar ola bilər.

İşə salmadan əvvəl təkrarlanan processing, tərəqqinin olmaması, taym-aut, 429, 5xx xətası, səhv JSON, gecikmiş vebhuk, duplicate-vebhuk, partial, canceled və naməlum status ssenarilərini yoxlayın. Test rejimi inteqrasiya strukturu üçün faydalıdır, lakin onun çatışmazlığı ondan ibarətdir ki, o, işlək API-nin real növbələrini və gecikmələrini təkrarlamaya bilər.