Restful API гэж юу вэ?

Zorig

Published in

limitx

6 min readOct 17, 2017

API гэж юу вэ?

Application Programming Interface гэсэн үгсийн товчлол.
Маш өргөн хүрээтэй ойлголт, компьютер, ухаалаг утас, компьютерийн чип гээд бүгд л өөрийн API -тай, гэхдээ одоо зөвхөн web -тэй холбоотой хэсгийг нь ярих болно.
Өөр нэг software өөр нэгэн software -тай харьцах зориулалттай.
Зөв бүтэц бүхий хүсэлт болон хариу.

Ер нь API гэж яг юу вэ? гэдэгт хариулахын тулд энгийн жишээ авч үзэе. Та олон сонголттой меню бариад рестораны ширээнд сууж байна, харин гал тогоо бол таны захиалгыг бэлдэх газар. Харин энд байхгүй нэг зүйл болох таны захиалгыг гал тогоонд хүргэж, бэлэн болмогц танд буцааж авч ирэх зөөгч буюу манай нөхцөлд “API” хэрэгтэй. Жинхэнэ API жишээ авч үзэе. Хэрэглэгч рестораны менютэй адилаар онгоцны тасалбар захиална гэвэл хэзээ нисэх, хаашаа нисэх гэх мэт мэдээллийг нислэгийн компанийн өгөгдлийн сангаас шүүж хардаг. Гэхдээ өөр нэг хувилбар нь хэрэв хэрэглэгч шууд нислэгийн компанийн вэбээс биш!, онлайн аялал жуулчлалын үйлчилгээ үзүүлэх газарт дээрхи мэдээллүүдийг оруулж тухайн үед боломжтой бүх авиа компанийн нислэгийн мэдээллийг шүүх үед нэг биш нилээд хэдэн газрын нислэгийн хуваарийг аялалын компанид явуулж та үүнийг нь харах юм. Тэгэхээр API нь төхөөрөмж(компьютер, ухаалаг утас... г.м) эсвэл аппликейшн, програм хооронд дата дамжуулах холболт юм.

https://www.javatpoint.com/fullformpages/images/api-full-form.png

Rest гэж юу вэ?

Representational State Transfer гэсэн үгсийн товчлол
Сүлжээгээр холбогддог аппликешн эсвэл програмийн архитектур загвар. Rest нь сүлжээ хоорондын харилцааг илүү уян хатан болгох зориулалттай.
client-server протокол aшигладаг, ихэнхдээ HTTP дээр тулгуурлсан

Rest бол тодорхой дүрмүүдийн дагуу системийг загварчлах архитектур.

Representational State Transfer -ыг Roy Fielding 2000 онд PHD дисертацдаа бичсэн байна. Тэрээр вэб-ыг яагаад бусад интернет протоколоосоо илүү амжилттай болж байгааг анзаарч судлан сүлжээний харилцааг илүү вэб-төст болгох загварыг гаргасан. Тэгэхээр REST нь ерөнхий хэдхээн зарчим бөгөөд яг ч вэб-д зориулсан эд биш юм. Үүнийг бусад сүлжээ болох Embedded system дээр ч ашиглаж болно. REST -ын зарчим нь хэд хэдэн асуултуудад хариулт өгдөг нь:

Систем яг ямар ямар компоненттэй(бүрэлдэхүүн хэсэг) байх вэ?
Эдгээр компонентууд хэрхэн хоорондоо харилцах вэ?
Хэрхэн системийн аль нэг хэсгийг бусаддаа нөлөөлөхгүй өөрчлөх, солих, устгах вэ?
Системийг хэрхэн хэдэн тэрбум хэрэглэгчид зориулж өргөтгөх вэ?

Roy Field -ын дурьдсанаар систем RESTful болохын тулд хэд хэдэн зарчмийг хангасан архитектуртай байх хэрэгтэй.

1. Client-Server

Эхний зарчим нь сүлжээний холболт заавал client болон server хооронд үүсэх ёстой. Server нь өгөгдлийг хадгалж буй компьютер, харин client нь server дээр байгаа өгөгдөлтэй ямар нэг байдлаар харьцах шаардлагатай. Жнь: Интернет хөтөчид ямар нэг URL бичээд хандахад таны компьютер client болж HTTP хүсэлт тухайн URL -ын зааж буй сервер рүү явуулна. Ингэж RESTful систем нь client-server гэсэн зарчимаар ажиллах ёстой. Client нь олон өөр төрөл байж болно; PC дээр ажиллах хөтөч, ATM, андройд утас г.м

RESTful биш ч гэсэн яг адилхан client-server архитектур нь event дээр суурилсан архитектур юм. Энэ нь компонент бүр event илгээхийн зэрэгцээ бусад компонентийн event-г сонсож байдаг. Ямар ч нэгээс нэгрүү холболт байхгүй, зөвхөн event үсэрч, бас сонсож байх архитектур нь RESTful биш юм.

2. Stateless

Client болон Server нь бие биенийхээ state(нөхцөл) -ыг байнга мэдэх шаардлагагүй ба хэрвээ client server-тэй ямар нэг холболт үүсгэхгүй бoл server тал client байгаа эсэхийг ч мэдэхгүй. Session хүртэл client талдаа хадгалагдах хэрэгтэй, учир нь сервер холболтын талаар ямар ч мэдээлэл өөр дээрээ хадгалахгүй байгаа. Ингэснээр хэрвээ сервер яг 1 хүнээс ирсэн 2 өөр хүсэлтийг адилхан client ээс ирсэн гэдгийг мэдэхгүй. Цаашлаад client -аас ирэх хүсэлт бүр бүх хэрэгтэй мэдээллээ, мөн сервер талд хийгдэх үйлдлийн талаар агуулж байна.

Ерөнхийдөө энэ зарчим нь RESTful API нь session ашиглалт буюу login, logout функцгүй байхыг шаарддаг. Тэгээд ч session ашиглах нь хориотой. Client нэвтрэхийн тулд, client талдаа нэвтрэх мэдээллийг агуулах, мөн хүсэлт тус бүрт тухайн мэдээллийг хавсаргадаг тул сервер хүсэлт бүрээс нэвтрэх мэдээллийг хайдаг. Нэг жишээ нь JSON web token юм.

3. Uniform interface

Сервер client 2уулаа ямар ч асуудалгүй ойлголцдог, client талдаа аль нэг бүрэлдэхүүн хэсгийг хасах, солих, өөрчлөх үед бүхэл системд ямар нэг алдаа гарахгүй(нэг нэгнээсээ хамаарал бага) байх ёстой. Нэгдсэн нэг байлгах үүднээс HTTP -ын CRUD(create, read, update, delete) үйлдлүүдийг RESTful API ашигладаг.

CREATE нь HTTP дээр POST хүсэлт болох ба шинээр үүсгэх үед хэрэглэнэ.
READ нь HTTP дээр GET хүсэлт болох ба өгөгдлийг авах, харах үед хэрэглэнэ.
UPDATE нь HTTP дээр PUT/PATCH хүсэлт болох ба өгөгдлийг шинэчлэх, өөрчлөх үед хэрэглэнэ.
DELETE нь HTTP дээр DELETE хүсэлт болох ба өгөгдлийг устгах үед хэрэглэнэ.

Uniform interface -ийн 4 дэд зарчим :

Interface зарчим 1: Серверээс ирэх датаг таних

Хамгийн эхний дэд зарчим нь серверээс ирэх датаг шинжлэх, таних юм. REST -ын дүрмэнд серверийн өгөгдөл нь юу ч байж болдог, HTML хуудас, зураг, ямар нэг хэрэглэгчийн мэдээлэл г.м. Өгөгдөл бүр давтагдашгүй, тогтвортой нэгэн ялгах шинж тэмдэгээр танигдана. Тогтвортой гэдэг маань өгөгдөл солилцох үед өөрчлөгдөхгүй гэсэн үг юм. Жишээ нь ID ч юм уу. Web нь HTTP түүний холболтын стандарт болон URI тусламжтай серверээс ирэх өгөгдлийг таньдаг. Сервер дээр хадгалагдсан мэдээллийг авахын тулд HTTP -ын GET хүсэлт явуулна. Интернет хөтөчийн хаягын нүдэнд юм бичихэд GET хүсэлт явуулдаг ба хэрвээ “200 ОК” болон HTML хуудас хариуд нь ирвэл хөтөч энэ хуудсыг render хийж та харах боломжтой болдог билээ.

Interface зарчим 2: Серверийн өгөгдлийг өөрчлөх

Client өгөгдлийг өөрчлөн серверрүү илгээх үед ихэвчлэн JSON явуулдаг ба энэ нь шинээр өгөгдөл нэмэх, устгах, эсвэл өөрчлөх мэдээлэл болон зааврыг агуулж байдаг. REST -д server нь бүх зүйлийг хийх ёстой ба client сервер дээрх өгөгдөлд өөрчлөлт хийхдээ серверрүү зөвхөн өөрчлөгдсөн өгөгдлийг явуулдаг. Жишээ нь хэрэглэгч шинэ нийтлэл блогтоо орууллаа, компьютер серверт HTTP POST хүсэлт явуулна. Сервер хүлээж аваад хариу болгон нийтлэл хэвлэгдсэн эсвэл алдаа гарсан аль нэг хариуг буцаана. REST биш үед, хэрэглэгч шууд “ энд шинэ мөр ав, дараа нь гарчиг болгон ийм текст бич … г.м” заавар хэлбэрээр явуулна.

Interface зарчим 3: Өөрөө өөрийгөө тодорхойлох захиас

Энэ нь хүлээн авагч нь ойлгох шаардлагатай бүх мэдээллийг агуулж байх өгөгдөл ба, тусдаа эсвэл үргэлжлэл болгон салангид хэлбэрээр өгөгдлийн үргэлжлэл араас нь ирж болохгүй. Вэб дээр хэрхэн ажиллахыг авч үзэе.

Хэрэглэгч http://www.example.com руу хандахад хөтөч дараах хүсэлтийг илгээнэ.

GET / HTTP/1.1
Host: www.example.com

Ажиглавал энд өөрөө өөрийгөө тодорхойлох үйлдэл хийгдэж байна. Энд ямар HTTP зарчим хэрэглэгдэж байгаа болон протокол нь агуулагдсан байна. Үүний дараа сервер магадгүй дараах хариуг буцаана гэж үзэе.

HTTP/1.1 200 OK
Content-Type: text/html<!DOCTYPE html>
<html>
  <head>
   <title> Нүүр Хуудас </title>
  </head>
  <body>
    <div>HELLO WORLD!</div>
  </body>
</html>

Дээрх нь мөн л өөрөө өөрийгөө тодорхойлж байна. Client-д хариуг хэрхэн илэрхийлэх талаар Content-Type -д зааж бүх л хэрэгтэй мэдээллээ нэгхэн хариуд авч чадаж байна.

Хэрвээ сервер binary код явуулаад, араас нь тусдаа тухайн binary кодыг илэрхийлэх хэлбэрийг нь явуулж тухайн хариуг зураг эсвэл код гэдгийг нь мэдэх гэж оролдож байх хооронд 3дахь хариу нь ирэх эсвэл бүр 3дахь хариу түрүүлээд хүрээд ирвэл яах вэ? тэр үед client хариуг хэрхэн зөв илэрхийлэх вэ гэдэг нь нилээд эргэлзээтэй.

Interface зарчим 4: hypermedia

Энэ дэд зарчим нь серверээс ирсэн өгөгдөл хэрэглэгчийг цааш явахад нь тус болохуйц холбоосуудыг агуулах hyperlink тэй байхыг шаарддаг. Жишээ нь хариу болгон HTML хуудас явуулах, тухайн хуудас дотроо

<a href="en.wikipedia.org">Wikipedia эх сурвалж</a> г.м холбоосыг агуулах юм.

Систем өгөгдөл бүрийг тодорхойлох таних, client-аас серверрүү өгөгдлийг өөрчлөх, өөрийгөө тодорхойлсон өгөгдөлтэй, мөн hypermedia агуулсан бол uniform interface тэй гэж үзэх нь.

Дээрх 4 дэд зарчим нь аль хэдийн HTTP -д байдаг. Тэгэхээр API нь HTTP -ыг зөв ашиглаж чадвал RESTful болох нь.

API нь REST -ын тодорхой хэдэн үйлдлүүдэд тодорхойлогдож чадаж байвал RESTful байна.

4. Caching

Сервереес ирэх хүсэлт нэг бол cache-лэх боломжтой, боломжгүй гэсэн 2 төрөл байх хэрэгтэй. Caching нь хэрэглэгч урьд нь үзсэн өгөгдлүүдийг дахин үзэх үед сүлжээний хүсэлт илгээхгүйгээр өөр дээрээ хадгалагдсан мэдээллийг харуулж нэг бүтэн тойрон аялал хэмнэдэг.

5. Layered system

Энэ нь зөвхөн сервер, client 2 оор хязгаарлагдахгүй гэсэн үг юм. Нэмээд хэд хэдэн давхарга байж болох ба Жишээ нь Proxy. Proxy нь ачааллыг тогтворжуулах, хамгаалалтын гэх мэт ашигтай. Яг сервер рүү хүсэлт явуулж буй client шиг, мөн client ээс хүсэлт авч буй сервер шиг ажиллах боломжтой.

6. Code on Demand

Энэ бол заавал биш зарчим. Сервер client руу шууд ажиллах боломж бүхий код явуулах ба одоогоор HTML -ын script таг дотор javascript дуудахад болдог үйл явц юм. HTML хуудас дуудагдаж дуусаад хөтөч автоматаар javascript -ыг сервер дээрээс дуудаж өөр дээрээ ажиллуулна.

Аль нэг сүлжээ Fielding -ийн зарчмыг хангаж байвал RESTful систем болох ба аль болох уян хатан, өөр өөр хувилбараар ашиглах боломжтой, өргөтгөхөд хялбар(Их хэмжээний хэрэглэгч, цаг хугацаа хэмнэх) систем бүтэх юм.