PHP və Laravel ilə API hazırlamaq yalnız ünvan yaradıb JSON qaytarmaq deyil. Müştəri tətbiqi, məlumat modeli və iş qaydası arasında müqavilə qurulur. Tətbiqin necə görünməsi dəyişə bilər, amma API-nin verdiyi məlumat və əməliyyat mənası istifadəçi axını ilə uyğun qalmalıdır.
İlk növbədə API-ni kimin istifadə edəcəyini yazın: saytın öz interfeysi, mobil tətbiq, daxili panel və ya tərəfdaş sistem. Bu seçim giriş və dəyişiklik qaydalarına təsir edir. Daha ümumi əlaqə məsələləri API inteqrasiyası bələdçisində izah olunur.
Əvvəl iş əməliyyatını təsvir edin
«Sifariş yarat» tələbinin daxilində müştəri, məhsullar, ünvan və razılaşdırılmış qiymət qaydası ola bilər. Hansı hissə istifadəçidən gəlir, hansını server hesablayır və hansı məlumat əsas mənbədən götürülür? Bunlar dəqiqləşmədən endpoint adının seçilməsi layihəni tam müəyyən etmir.
İzahlı nümunə: mobil tətbiq sifariş göndərir. Bu şərti ssenaridə tətbiqin göndərdiyi yekun məbləğə kor-koranə inanmaq əvəzinə serverin hansı qaydaya əsaslanacağı yazılmalıdır. Eyni zamanda proqramçı biznesin kommersiya hesabını özü uydurmamalıdır; qayda səlahiyyətli tərəfdən gəlir.
Sorğu və cavab müqaviləsi
- Sahə adları və məlumat növləri.
- Məcburi və istəyə bağlı dəyərlər.
- Tarix və boş dəyər formatı.
- Uğurlu nəticənin nümunəsi.
- Düzəldilə bilən səhvin təqdimatı.
- Səhifələmə və axtarış davranışı.
Nümunələr həm hazırlayan, həm istifadə edən tərəf üçün anlaşılan olmalıdır. Bir sahənin boş sətrə, sıfıra və ya məlum olmayan qiymətə çevrilməsi fərqli məna yaradır. Cavabda istifadə edilməyən şəxsi və texniki məlumatların «bəlkə lazım olar» deyə qaytarılması düzgün məlumat müqaviləsi deyil.
Validation iş qaydasını əvəz etmir
Laravel-in validation sənədi daxil olan sahələrin yoxlanılması üçün vasitələri göstərir. Lakin e-poçtun formatının düzgün olması həmin istifadəçinin konkret sifarişə girişini təsdiqləmir. Sahə yoxlaması və əməliyyat icazəsi ayrı suallardır.
Məsələn, məhsul identifikatoru rəqəm ola bilər, amma istifadəçinin təşkilatına aid olmaya bilər. Eyni şəkildə tarix formatca doğrudur, lakin iş qaydasına uyğun intervaldan kənardır. Texniki yoxlama biznesin razılaşdırılmış sərhədləri ilə tamamlanmalıdır.
Giriş və konkret qeydə icazə
API istifadəçini və ya tərəfdaş hesabını müəyyən etməli, sonra əməliyyatın həmin obyekt üçün icazəsini yoxlamalıdır. Menyuda görünməyən link API-ni qorumur. İstifadəçi başqa sifarişin identifikatorunu göndərdikdə də eyni qayda tətbiq olunmalıdır.
Çoxşirkətli modeldə təşkilat konteksti hər sorğu üçün aydın saxlanır. Səlahiyyət məqaləsindəki rol matrisini API sınaqlarına çevirmək yaxşı başlanğıcdır. Yalnız uğurlu sorğunu yoxlamaq kifayət deyil; qadağan edilən halları da sınamaq lazımdır.
Əməliyyatın bütövlüyü
Bir iş bir neçə əlaqəli məlumat dəyişirsə, yarımçıq nəticənin necə qarşısının alınacağı planlaşdırılmalıdır. Laravel verilənlər bazası sənədi tranzaksiya imkanlarını təsvir edir. Konkret sərhəd isə əməliyyatın hansı dəyişikliklərinin birlikdə tamamlanmalı olduğundan asılıdır.
Xarici ödəniş və ya mesajlaşma xidməti ilə yerli bazanın dəyişməsi həmişə bir sadə tranzaksiya deyil. Gözləmə, təsdiq və təkrar cəhd qaydaları ayrıca düşünülür. «Hər şeyi geri qaytar» ifadəsi başqa sistemdə artıq baş vermiş hadisəni avtomatik ləğv etmir.
Dəyişiklik və versiya planı
Mobil tətbiqin bütün istifadəçiləri eyni anda yenilənməyə bilər. API cavabındakı sahəni qəfil silmək köhnə tətbiqi poza bilər. Hansı dəyişikliklərin uyğun qalacağı, hansı dəyişiklik üçün ayrıca keçid lazım olduğu əvvəl razılaşdırılmalıdır.
Texniki sənəddə nümunə sorğu-cavablarla yanaşı səhv vəziyyətləri və autentifikasiya izahı da olmalıdır. Açar və həqiqi parollar nümunəyə daxil edilmir. Flutter tətbiqi planlaşdırılırsa, API ilə mobil versiyanın əlaqəsi həmin mərhələdə nəzərə alınmalıdır.
Nümunə: iki proqram versiyası eyni API-dən istifadə edir
Yeni interfeys bir sahəni başqa formada göstərir, amma köhnə mobil versiya əvvəlki cavabı gözləyir. Bu şərti vəziyyətdə serveri dəyişmək yalnız yeni ekranın yoxlanması ilə bitmir. Köhnə müştərinin hansı müddət və qayda ilə dəstəklənəcəyi yazılır.
Yeni sahə əlavə etmək, mövcud sahənin mənasını dəyişmək və sahəni silmək eyni dəyişiklik deyil. Komanda bu təsiri nümunə cavablarla görməlidir. Uyğunluq qaydası qəbul edilmiş müqavilənin hissəsidir, yalnız proqramçının yaddaşına buraxılmır.
- Köhnə və yeni sorğu nümunəsini saxlayın.
- Əsas sahələrin mənasının dəyişmədiyini yoxlayın.
- Boş və səhv cavabları hər iki müştəridə müqayisə edin.
- Keçid tələb edən dəyişiklik üçün tarix və plan yazın.
Bu yanaşma hər kiçik yenilik üçün böyük versiya sistemi yaratmaq demək deyil. Məqsəd istifadə olunan müqaviləni təsadüfən pozmamaq və dəyişiklik lazım olduqda anlaşılan keçid təmin etməkdir.
Tez verilən suallar
Laravel bütün təhlükəsizliyi avtomatik həll edirmi?
Freymvork alətlər verir, amma konkret məlumat, icazə və biznes qaydaları tətbiq tərəfindən düzgün qurulmalıdır.
Başlanğıcdan çox böyük API lazımdırmı?
Əsas istifadə ssenarilərini tamamlayan aydın ilk versiya daha nəzarət olunan başlanğıcdır. Sonrakı genişlənmə müqavilə əsasında aparılır.
Elang PHP portfolioda sənədləşmə və praktik nümunələr platforması kimi təqdim olunur. Öz API layihəniz üçün API xidməti çərçivəsində iş axını, sorğu və qəbul nümunələrini hazırlayın.
API planından işlək backend-ə
Texniki tapşırıq hazırdırsa, PHP və Laravel hazırlanması çərçivəsində məlumat modeli, biznes qaydaları və inteqrasiya sınaqları üzrə iş bölgüsü aparılır. API müqaviləsi ilə idarəetmə ehtiyacları birlikdə nəzərə alınır.
