nedir-axi-bu-rest

Nədir axı bu REST?

                REST servislər haqda saytımızda bir neçə məqalə yayımlansa da, ən təməl bilgilər haqda hələ də məlumat verməmişdik. Bu məqalədə həmin boşluğu dolduraraq aşağıdakı suallara cavab verməyə çalışacağıq:

1)API(ey-pi-ay şəkildə oxunur) nədir?

2)Web based API özlüyündə nədir?

3)nədir axı bu REST?

4)REST-ə ehtiyacın səbəbləri

5)REST constraint-lər hansılardır?

PS:

SOAP və REST servislər haqda aşağıdakı məqalələrimizi oxuya bilərsiniz:

Soap və REST servislərin fərqi

WCF və Web API-nin fərqləri. Hansını seçməli

OBYEKTYÖNÜMLÜ PROQRAMLAŞDIRMA VƏ SOA ARASINDAKI FƏRQLƏR NƏLƏRDIR?

ASP.NET CORE WEB API VERSIONING PROSESI



APİ nədir?

               Proqram təminatı hazırlayarkən  bəzi işləri təkrar-təkrar yerinə yetirməmək üçün APİ(Application programming İnterface) yazırıq. APİ bizi işlədiyimiz environment və domein sahəsinin çətinliklərindən izolyasiya edərək , qəliz proseslərin inkapsulyasiyasını, domen sahəsindən abstraksiya olunmağımızı təmin edir. Bunun hesabına, aşağı səviyyəli (low-level design) arxitektur həllərdən uzaqlaşaraq sadəcə verilən interfeys üzərindən mühitlə əlaqə saxlayırıq. Misalçün  framework istifadə edərkən funksionallıqlarından faydalandığımız bütün dll-lərə(paketlərə) APİ olaraq baxa bilərik.


Web based API özlüyündə nədir?

               Web Based API - sadəcə APİ-ın bir variasiyasıdır. Web Based API APİ-nin bir forması olub, veb standart və protokolları istifadə edərək application-lararası məlumat mübadiləsini təmin etmək üçün istifadə olunur.  Adəti üzrə bu tip APİ-lər özlərini REST APİ və SOAP servislər şəklində biruzə verir. Bunun hesabına müxtəlif veb resurslar(sayt,servis və s) arasında kanal yaradaraq, böyük bir infrastruktur(microservis və bənzəri) və ya sadəcə mübadilə müxanizmi qurmaq olur.

               Bügunki məqalənin əsas mövzusu Web Based API formalarından biri olan RESTful Servislər olacaq.

Nədir axı bu REST?

               REST(Representational State Transfer) – http protokolu üzərindən bir-biriylə zəif asılılığı olan(loosely-coupled) proqramlar hazırlamaq üçün istifadə olunan arxitektur stildir. REST sadəcə bir arxitektur stildir. Arxitektur stil odur ki, hər hansı bir işin yuxarı səviyyəli arxitektur dizaynı verilsə də(hig-level design), aşağı səviyyəli dizaynı(low-level design) realizə edən(vendor, provayder) tərəf üçün sərbəst saxlanılır.

               REST bir standart deyil. REST standart olmasa da, müasir dövrdə veb standartlar vasitəsilə realizə olunur.

               REST bir protokol deyil. REST protokol olmasa da, müasir dövrdə veb protokollar(http) vasitəsilə realizə olunub. Amma REST protocol-independent(protokoldan asılı olmayan) xarakterə malikdir. Onun http prokolu ilə realizə olunması yalnız bu protokol ilə işləyə biləcəyi anlamına gəlmir.

               Siz REST-i bir nöz İSO/OSİ modelinə bənzədə bilərsiniz. İdeal model olsa da, real praktikada TCP/İP modeli istifadə olunur və İSO/OSİ bir növ teoriyada qalıb. REST teoriyada qalmasa da, gələcəkdə başqa formatda realizə oluna biləcəyi istisna deyil.

               REST-in işini praktiki formada 1 cümlə ilə ifadə etsək deyə bilərik ki, “Klient serverə sorğu göndərir, Server gələn cavaba uyğun klientin state-ini(vəziyyətini) dəyişir”.

REST sözünün məğzinə gəlincə.. REST-in əsasında Resurs, Representation, State və Transfer anlayışları dayanır.  İlk öncə, klient serverə müraciət edərək ondan resurs istəyir. Server resursun originalını özündə saxlayaraq, sadəcə onun bir nüsxəsi olan Representation-i göndərir klientə. Sabah resurs dəyişikliyə uğrasa, klient yenidən sorğu verməli və resursun ən son state-ni yenidən almalıdır. Resursun serverdən klientə ötürülməsi isə sadəcə Transferdir.

               REST-ə ehtiyacın səbəbləri:

1)     Klient və Serveri bir-birindən izolyasiya edərək onlar arasındakı asılılığı aradan qaldırır.

2)     Hansısa platformadan asılı deyil

3)     Hansısa proqramlaşdırma dilindən asılı deyil. Siz istər PHP, istər C#, istər Node.js vəs. ilə REST servislər yaza bilərsiniz.

4)     Konkret bir formata bağlı deyil. Siz məlumatları istər XML, istər JSON ilə(başqa formatlar da ola bilər) ala bilərsiniz.

5)     Distributed sistemlər qurmağa imkan verir

6)     Discoverable xüsussiyyətə malikdir. Digrə resursları identifiaksiay etmək olur

7)     İstifadəsi çox asandır

8)     Http cache istifadə edə bilir

 

REST constraint-lər hanslardır?

               Bir servisin REST olub-olmadığını göstərən əsas mexanizm onun məhdudiyyətləridir(constraint).

REST-in 6 (5 məcburi , 1 sərbəst) məhdudiyyətləri var.

1)Uniform-İnterface Constraint – Bu məhdudiyyət bəlkə də, REST konsteintlər araısnda ən önməli olan məhdudiyyətdir. Təməlində dayanan əsas ideyaları qısa sadalamaq lazım olsa belə deyə bilərik:

               -Müxtəlif qurğu,avadanlıq və proqramlar eyni bir url üzərindən resusrları istifadə etməlidir

               -Bir url fərqli-fərqli representation(təsvir) təqdim edə bilər. Bu adətədn servislərdə Content Negatiation olaraq verilir. Yəni eyni bir url-ə müraciət edərək, konfiqdən asılı olaraq məlumatı həm xml, həm JSON formatda ala bilərsən    .

               -Eyni bir url-ə həm GET, həm POST sorğusu verə bilirik

Əslində, yuxarıdakı qısa icmal tam deyil. Çünki Uniform-interface constraint-i özlüyündə 4 alt-hissədən ibarətdir. Onları bilməsək, tam şəkildə bu məhdudiyyətin nə işə yaradığını anlamaq çətin olur:

1.1  İdentification of Resources- Resursların identifikasiyası url üzərindən yerinə yetirilməlidir. Yəni url-ə baxdıqda hansı tip resurs istifadə olunduğunu bilmək asan olmalıdır. Misal: Əgər http://sayt.com/students url-i verilibsə, burada students bizim çağrılıb isitfadə olunan rsursumuz olur. Resursun adı url-də əks olunmalıdır.

1.2  Manipulating Resources through representation(Resurslara təsvir üzərindən manipulyasiya) –Əgər sorğu verən klientin resursa manipulyasiya(edit,delete) icazəsi varsa, geriye qayidan representation ilə birgə, resursa necə manipulyasiya edəcəyi haqda metadatalar olmalıdır. Bu metadata-linklər vasitəsilə çağrılan resursu deyişmək və ya silmək olar.

1.3  Self-descriptive messages- Hər göndərilən sorğu özlüyündə tam olmalıdır, hər hansı bir atomar işi görmək üçün əlavə əmrlərə ehtiyac olmamalıdır. Adəti üzrə meta məlumatlar(əlavə credential-lar, http method məlumatı, meta infolar) http header-lər vasitəsilə göndərilir.

1.4  HATEOAS –(Hypermedia As The Engine of Application State) – hər bir sorğu əsnasında WCF servislərdə WSDL olduğu kimi, burada da documentation məlumatları almaq mümkün olmalıdır. Məğz ondan ibarətdir ki, klient tərəfi digər resursların harada yerləşdiyini rahatlıqla bilməlidir(discoverable)

2)Client-Server constraint(Klient Server məhdudiyyəti) –Bu məhdudiyyət imkan yaradır ki, klient və serveri bir-birindən izolyasiya edək.

-Məlumat mübadiləsi üçün klient və server olmalıdır

-Onları müstəqil müşayiət etmək, genişləndirmək olmalıdır

-Bir-birlərindən asılı olmamlıdırlar

-Klient serverin arxitekturasi haqda nəsə bilməyinə ehtiyac olmamalıdır

-Server klientin Uİ-ı haqda nəsə bilməyinə ehtiyac olmamalıdır

3)Stateless constraint- bu məhdudiyyət hesabına server və klient bir biri haqda məlumata malik olmadan genişlənə bilir.

-Server klient haqda heç bir seans(data) saxlamamlıdır

-Klient və serverin münasibəti stateless yerinə yetirilir və sorğuların hamısı tam müstəqil sorğu olmalı, digər sorğuların nəticəsindən asılı olmamalıdır

4)Cachable constraint – məqsəd şəbəkəyə qənaət etmək, mübadilə sürətini artırmaqdır

-Mümkün olduğu hallarda serverdən gələn sorğunu cache-da saxlamaq lazımdır

-Hər response zamanı header vasitəsilə cache-i idarəetmək mümkün olmalıdır

5)Layered system-məqsəd complexityni(çətinlik dərəcəsi) azaltmaqdır.

-Server arxitekturasi ierarxik layer(örtük-abstraksiya səviyyəsi)-ə bölünür

-Hər layer yalnız orta layerdən xəbəri var

6)Code on demand constraint-bu məhdudiyyət optional(məcburi olmayan)-dir.

-Sadə datalardan əlavə server klientə hansısa icra olunan kod nümunəsini icra etmək imkanı yarada bilər.Misalçün JS kod icra etmək. Sədəcə bu tip məhdudiyyət nisbətən təhlükəli olduğuna görə onu realizə etmək məcburiyyəti yoxdur.


Tural

Tural Süleymani

Süleymani Tural Microsoft-un MCSD statuslu mütəxəssisidir, 2008-ci ildən bu yana proqramlaşdırma üzrə tədris aparır

Müəllifin bu dildə ən son postları

Bu yazıları da bəyənə bilərsiniz