REST və GraphQL: hansı API üslubunu seçməli?

REST də, GraphQL də eyni əsas problemi həll edir — müştəri tərəfinə HTTP üzərindən serverdən məlumat istəməyə imkan verir — lakin bunu müxtəlif kompromislərlə edir və onlar arasındakı seçimə çox vaxt lazım olduğundan daha ideoloji yanaşılır. Heç biri sadəcə «daha yaxşı» deyil. Hər biri müəyyən növ məhsullara və komandalara digərindən daha yaxşı uyğun gəlir.

REST necə işləyir və harada özünü doğruldur

REST API-ni resurslar ətrafında qurur — istifadəçi üçün bir URL, sifariş üçün bir URL, məhsullar siyahısı üçün bir URL — və onlar üzərində əməliyyatlar üçün standart HTTP metodlarından (GET, POST, PUT, DELETE) istifadə edir. O, veb-API-lər üçün o qədər uzun müddətdir standart yanaşmadır ki, alətlər, keşləmə davranışı və komandaların onunla tanışlığı tam yetkinləşib. İstənilən HTTP keşi, CDN və brauzer GET sorğusunu URL üzrə necə keşləməyi artıq bilir — bu, REST-in «pulsuz» əldə etdiyi real, praktik üstünlükdür.

REST müştəri tərəfinə bir neçə resursu əhatə edən məlumat lazım olanda əlverişsizləşir. İstifadəçinin profilinə, onun son beş sifarişinə və hər sifarişin mövqelərinə ehtiyacı olan mobil tətbiq ekranı üç-dörd ayrıca REST sorğusu və ya sırf həmin ekran üçün yaradılmış xüsusi birləşdirilmiş endpoint tələb edə bilər — bu endpoint isə məhsul böyüdükcə ekrana xas digər endpoint-lərlə birlikdə dəstəklənməlidir.

GraphQL necə işləyir və harada özünü doğruldur

GraphQL modeli tərsinə çevirir: hər endpoint-in hansı formada məlumat qaytaracağına server qərar vermək əvəzinə, müştəri tərəfi ona lazım olan sahələri — ehtimal ki, bir neçə əlaqəli resurs üzrə — dəqiq təsvir edən sorğu göndərir və tam olaraq onu alır: nə artıq, nə əskik. Bu tək sorğu çevikliyi əsas üstünlükdür və hər biri eyni məlumatların bir qədər fərqli hissəsinə ehtiyac duyan çoxsaylı müştəri ekranları və ya tətbiqləri (veb, iOS, Android) olan məhsullar üçün həqiqətən dəyərlidir, çünki bir çevik sxem fərdi endpoint-lərin sayını artırmadan hamısına xidmət edə bilər.

Kompromislər burada da realdır. Keşləmə daha çətindir, çünki GraphQL API adətən çoxsaylı keşlənə bilən GET URL-ləri deyil, tək POST endpoint-idir, ona görə də standart HTTP keşləməsinə arxalanmaq əvəzinə xüsusi keşləmə (persisted queries, Apollo və ya Relay kimi müştəri tərəfində normallaşdırılmış keşlər) lazımdır. Server tərəfində sorğuların mürəkkəbliyini aktiv idarə etmək lazımdır, çünki müştəri texniki olaraq sadə REST endpoint-inin heç vaxt icazə verməyəcəyi dərin iç-içə, «baha başa gələn» sorğu göndərə bilər. Bununla yanaşı, GraphQL ilə yeni tanış olan komanda üçün öyrənmə çətinliyi — sxem dizaynı, resolver-lər, müştəri alətləri — REST-dəkindən daha yüksəkdir.

Praktik qərar

• REST-i seçin, əgər məlumat modeliniz daha sadədirsə, müştəri tipləri azdırsa, standart HTTP keşləməsinə və alətlərinə arxalanmaq istəyirsinizsə və ya komandanız onu artıq yaxşı bilirsə və məhsul daha artığını tələb etmirsə.
• GraphQL-i seçin, əgər eyni backend üzərindən bir neçə çox fərqli müştəri tətbiqinə xidmət edirsinizsə, məlumat modeliniz həqiqətən relyasiyalıdırsa və müştərilər tez-tez bu əlaqələri bir sorğuda keçməli olurlarsa, yaxud REST ilə artıq və ya natamam məlumat yükləmə (over-fetching və under-fetching) hipotetik deyil, real, təkrarlanan problemə çevrilibsə.
• Heç biri bütöv sistem üçün «ya hamısı, ya heç nə» seçimi olmalı deyil — bir çox real məhsul sadə CRUD servisləri üçün REST-dən, müştəriyə yönəlmiş sorğular üçün isə onların qarşısında aqreqasiya qatı kimi GraphQL-dən istifadə edir, yaxud əksinə.

API üslubundan daha vacib olan nədir

Hansını seçməyinizdən asılı olmayaraq, API ilə uzunmüddətli işin rahat olub-olmamasını müəyyən edən amillər hər iki halda eynidir: aydın və ardıcıl adlandırma, hər şeyə 200 qaytarmaq əvəzinə düzgün xəta emalı, ağlabatan səhifələmə (pagination) və həqiqətən aktual saxlanılan sənədləşmə. Yaxşı layihələndirilmiş REST API pis layihələndirilmiş GraphQL API-dən həmişə üstündür və əksinə — format onun arxasında dayanan intizamdan qat-qat kiçik amildir.

Məhsulun real quruluşuna uyğun API arxitekturasını seçmək — sadəcə daha dəbdə olan variantı deyil — Burncode-da qurduğumuz hər backend-də gördüyümüz proqram təminatının hazırlanması və veb-proqramlaşdırma işlərinin bir hissəsidir, çünki ondan çox müştəri tətbiqi ondan asılı olduqdan sonra burada səhv seçimi geri qaytarmaq baha başa gəlir.