API сервер нь гадны програмуудаас ирсэн бүх API хүсэлтийг хүлээн авдаг. Хэрэглэгчдийг баталгаажуулахын тулд API сервер нь нийтийн түлхүүрийн шифрлэлттэй төстэй баталгаажуулалтын системийг ашигладаг.

Нийтийн түлхүүрийн криптографийн систем (эсвэл тэгш бус шифрлэлт, тэгш бус шифр) - шифрлэлт ба / эсвэл цахим систем цахим гарын үсэг(EDS), үүнд нийтийн түлхүүрнээлттэй (өөрөөр хэлбэл хамгаалалтгүй, ажиглалтад ашиглах боломжтой) сувгаар дамждаг бөгөөд тоон гарын үсгийг баталгаажуулах, мессежийг шифрлэхэд ашигладаг. EDS үүсгэх, мессежийн кодыг тайлахын тулд үүнийг ашигладаг Нууц түлхүүр.

API серверийн бүх хүсэлтийг урд хянагч файлд хийдэг. Энэ файлд нийтийн болон хувийн түлхүүрүүдийг тодорхойлсон байдаг.

Энд алхам алхмаар тайлбарэнэ үйл явц:

• API үйлчлүүлэгчийн хүсэлт урд хянагч файлын байршил дахь серверт ирдэг. Хүсэлт нь APP ID (үйлчлүүлэгчийн нийтийн түлхүүр) болон APP KEY (үйлчлүүлэгчийн хувийн түлхүүрээр шифрлэгдсэн 32 тэмдэгтийн мөр)-г агуулна. Нууц түлхүүрийг хэзээ ч сервер рүү илгээдэггүй, зөвхөн хүсэлтийг шифрлэхэд ашигладаг. Хүсэлт нь сервер дуудлагын параметрүүдийг агуулдаг - хэрэглэгч, нэвтрэх нууц үг, хянагчийн нэр, үйлчлүүлэгчийн дуудлагыг боловсруулах ёстой үйлдэл. Жишээлбэл, сонголтуудын массив дараах байдалтай байж болно.

$items = массив("хянагч" => "todo", "action" => "унших", "хэрэглэгчийн нэр" => $хэрэглэгчийн нэр, "хэрэглэгчийн нэвтрэх" => $хэрэглэгч);

• API серверт хүсэлт ирэхэд сервер нь програмуудын жагсаалтыг нийтийн түлхүүр (APP ID) байгаа эсэхийг шалгадаг;
• Хэрэв нийтийн түлхүүр олдохгүй бол "Хүсэлт" төрлийн үл хамаарах зүйл хүчин төгөлдөр бус". Хэрэв түлхүүр байгаа бол сервер энэ нийтийн түлхүүрт тохирох нууц түлхүүрийг авч, ирж буй хүсэлтийн шифрийг тайлахыг оролдоно;
• Хэрэв шифрлэлт амжилттай болсон бол хянагч болон үйлдлийн параметрүүдийг ирж буй хүсэлтээс гаргаж авч боловсруулна. Хүсэлтийг зохицуулдаг урд хянагч холбогддог хүссэн файлхянагч ба үйлдлийн параметрт агуулагдах үйлдлийг дууддаг;
• Хүсэлтийг боловсруулахад амжилттай/бүтэлгүйтсэн тохиолдолд үйлчлүүлэгч API серверээс хариу хүлээн авна.

Noveo вэб хөгжүүлэгч Владимир хэлэв

Ихэнх вэбсайт, вэб үйлчилгээ, гар утасны програм хөгжүүлэгчид эрт орой хэзээ нэгэн цагт үйлчлүүлэгч-серверийн архитектуртай ажиллах, тухайлбал вэб API боловсруулах эсвэл түүнтэй нэгтгэх шаардлагатай болдог. Цаг бүр шинэ зүйл зохион бүтээхгүйн тулд ижил төстэй системийг хөгжүүлэх туршлага дээр үндэслэн вэб API дизайны харьцангуй түгээмэл хандлагыг хөгжүүлэх нь чухал юм. Бид таны анхаарлын төвд энэ асуудлын талаархи цуврал нийтлэлүүдийг хүргэж байна.

Эхний арга: Жүжигчид

Нэгэн сайхан мөчид, дараагийн вэб үйлчилгээг бий болгох явцад би вэб API зохион бүтээх сэдвийн талаархи бүх мэдлэг, бодлоо цуглуулж, үйлчлүүлэгчийн програмуудын хэрэгцээнд нийцүүлэн тэдгээрийг нийтлэл эсвэл нийтлэл хэлбэрээр зохион байгуулахаар шийдсэн. цуврал нийтлэлүүд. Мэдээжийн хэрэг, миний туршлага үнэмлэхүй гэж хэлэхгүй бөгөөд бүтээлч шүүмжлэл, нэмэлтүүд нь таатай байх болно.

Унших нь техникийн гэхээсээ илүү гүн ухааны шинжтэй байсан ч техникийн хэсгийг хайрлагчдын хувьд энд бодох зүйл байх болно. Энэ нийтлэлд би өөрийнхөө тухай хэзээ ч сонсож, уншиж, бодож байгаагүй цоо шинэ зүйлийг хэлнэ гэдэгт би эргэлзэж байна. Зүгээр л бүх зүйлийг өөртөө багтаахыг хичээдэг нэг систем, юуны түрүүнд таны толгойд байгаа бөгөөд энэ нь аль хэдийн маш их үнэ цэнэтэй юм. Гэсэн хэдий ч миний зохиосон бүтээлүүд таны практикт хэрэг болох юм бол би баяртай байх болно. Ингээд явцгаая.

Үйлчлүүлэгч ба сервер

СерверЭнэ тохиолдолд бид HTTP хүсэлтийг хүлээн авч, түүнийг боловсруулж, хүчинтэй хариу буцаах чадвартай сүлжээн дэх хийсвэр машиныг авч үздэг. Энэ нийтлэлийн хүрээнд оюутны зөөврийн компьютер эсвэл дэлхий даяар тархсан үйлдвэрлэлийн серверүүдийн асар том кластер эсэхээс үл хамааран түүний физик мөн чанар, дотоод архитектур нь огт чухал биш юм. Бүрээсний доор юу байгаа, хэн хүсэлтийг үүдэнд нь хүлээж авах вэ, Apache эсвэл Nginx, ямар үл мэдэгдэх араатан, PHP, Python эсвэл Ruby үүнийг боловсруулж, хариу үүсгэдэг, ямар мэдээллийн санг ашигладаг нь бидэнд огт хамаагүй: Postgresql , MySQL эсвэл MongoDB . Хамгийн гол нь сервер нь хариултыг сонсох, ойлгох, уучлах гэсэн үндсэн дүрмийг хангасан явдал юм.

ҮйлчлүүлэгчЭнэ нь HTTP хүсэлтийг үүсгэж, илгээх боломжтой бүх зүйл байж болно. Энэ нийтлэлийн тодорхой үе хүртэл бид үйлчлүүлэгч энэ хүсэлтийг илгээхдээ өөртөө тавьсан зорилго, мөн хариултыг юу хийх талаар сонирхохгүй байх болно. Үйлчлүүлэгч нь хөтөч дээр ажиллаж байгаа JavaScript скрипт байж болно. гар утасны програм, сервер дээр ажиллаж байгаа хорон муу (эсвэл тийм биш) демон, эсвэл хэтэрхий ухаалаг хөргөгч (тийм хүмүүс аль хэдийн байдаг).

Ихэнх тохиолдолд бид дээрх хоёрын харилцах арга барилын талаар ярих болно, тэд бие биенээ ойлгодог, хэнд нь асуулт байхгүй.

REST философи

REST (Represational state transfer) нь анхандаа сүлжээний шууд хадгалалт (сервер) бүхий цөөн хэдэн үндсэн үйлдлүүдийг багтаасан өгөгдлийн менежментийн энгийн бөгөөд хоёрдмол утгагүй интерфейс хэлбэрээр бүтээгдсэн: өгөгдөл хайх (GET), хадгалах (POST), өөрчлөх (PUT / PATCH) болон устгах (УСТГАХ). Мэдээжийн хэрэг, энэ жагсаалтад хүсэлтийн алдаатай ажиллах (хүсэлтийг зөв боловсруулсан эсэх), өгөгдөлд хандах хязгаарлалт (гэнэт та үүнийг мэдэхгүй байх ёстой), ирж буй өгөгдлийг баталгаажуулах (гэнэт та утгагүй зүйл бичсэн) гэх мэт сонголтуудыг үргэлж дагалддаг. Ерөнхийдөө серверийн хүслийг биелүүлэхээс өмнө хийж болох бүх шалгалтууд үйлчлүүлэгч.

Нэмж дурдахад REST нь архитектурын хэд хэдэн зарчимтай бөгөөд тэдгээрийн жагсаалтыг REST-ийн бусад нийтлэлээс олж болно. Хаашаа ч явах шаардлагагүй байхын тулд тэдгээрийг товчхон авч үзье.

Үйлчлүүлэгчээс серверийн бие даасан байдал- серверүүд болон үйлчлүүлэгчид хоорондын интерфейс өөрчлөгддөггүй тул бие биенээсээ үл хамааран бусад хүмүүсээр шууд сольж болно. Сервер нь үйлчлүүлэгчийн төлөвийг хадгалдаггүй.
Нөөцийн хаягуудын өвөрмөц байдал- өгөгдлийн нэгж бүр (ямар ч төрлийн үүрлэсэн) өөрийн гэсэн өвөрмөц URL-тэй байдаг бөгөөд энэ нь үнэндээ нөөцийн өвөрмөц танигч юм.

Жишээ:/api/v1/users/25/name АВАХ

Мэдээллийн хадгалалтын форматыг дамжуулах форматаас хараат бус байдал- сервер нь олон төрлийн дэмжлэг үзүүлэх боломжтой янз бүрийн форматуудижил өгөгдлийг (JSON, XML гэх мэт) дамжуулах боловч дэмжигдсэнээс үл хамааран өгөгдлийг дотоод форматаар нь хадгалдаг.

Хариултад шаардлагатай бүх мета өгөгдөл байгаа эсэх- өгөгдлөөс гадна сервер нь хүсэлтийг боловсруулах дэлгэрэнгүй мэдээллийг, тухайлбал, алдааны мэдэгдэл, шаардлагатай янз бүрийн нөөцийн шинж чанаруудыг буцааж өгөх ёстой. цаашдын ажилтүүнтэй хамт, жишээлбэл, цуглуулгын нийт оруулгуудын тоо зөв дэлгэцхуудасны навигаци. Бид янз бүрийн төрлийн нөөцийг авч үзэх болно.

Бидэнд юу дутагдаж байна

Сонгодог REST нь үйлчлүүлэгчийн сервертэй өгөгдлийн агуулах хэлбэрээр ажиллахыг илэрхийлдэг боловч хоорондоо өгөгдлийн холболт, харилцан хамаарлын талаар юу ч хэлдэггүй. Энэ бүхэн нь анхдагчаар үйлчлүүлэгчийн програмын мөрөн дээр бүрэн унадаг. Гэсэн хэдий ч нийгмийн үйлчилгээ эсвэл интернет маркетингийн систем гэх мэт мэдээллийн менежментийн системийг боловсруулж буй орчин үеийн сэдвүүд нь мэдээллийн санд хадгалагдсан байгууллагуудын хоорондын нарийн төвөгтэй харилцааг илэрхийлдэг. Эдгээр холбоосуудын дэмжлэг, i.e. өгөгдлийн бүрэн бүтэн байдлыг серверийн тал хариуцдаг бол үйлчлүүлэгч нь зөвхөн энэ өгөгдөлд хандах интерфейс юм. Тэгэхээр REST-д бидэнд юу дутагдаж байна вэ?

Функцийн дуудлага

Өгөгдөл болон тэдгээрийн хоорондын холбоосыг гараар өөрчлөхгүйн тулд бид зүгээр л нөөц дээрх функцийг дуудаж, шаардлагатай өгөгдлийг аргумент болгон "тэжээх" болно. Энэ үйлдэл нь REST стандартад тохирохгүй, үүнд зориулсан тусгай үйл үг байдаггүй бөгөөд энэ нь биднийг хөгжүүлэгчдийг нэг дор гаргахад хүргэдэг.

Хамгийн энгийн жишээ- хэрэглэгчийн зөвшөөрөл. Бид нэвтрэх функцийг дуудаж, итгэмжлэлийг агуулсан объектыг аргумент болгон дамжуулж, хариуд нь хандалтын түлхүүр хүлээн авдаг. Сервер талын өгөгдөлд юу тохиолдох нь бидэнд төвөг учруулахгүй.

Өөр сонголт- Өгөгдөл хоорондын холбоос үүсгэх, таслах. Жишээлбэл, бүлэгт хэрэглэгч нэмэх. Байгууллага руу залгаж байна Бүлэг addUser функц, объектыг параметр болгон дамжуулна хэрэглэгч, бид үр дүнг авдаг.

Мөн түүнчлэнМэдээллийг хадгалахтай шууд холбоогүй үйлдлүүд байдаг, жишээлбэл, мэдэгдэл илгээх, аливаа үйлдлийг баталгаажуулах, татгалзах (тайлангийн хугацааны төгсгөл гэх мэт).

Олон үйлдэл

Энэ нь ихэвчлэн ийм зүйл тохиолддог бөгөөд үйлчлүүлэгч программ нь нэг хүсэлтээр хэд хэдэн нэгэн төрлийн объектыг нэгэн зэрэг үүсгэх / өөрчлөх / устгах / хийх нь илүү тохиромжтой гэдгийг үйлчлүүлэгч хөгжүүлэгчид ойлгох болно. боломжтой. Энд дор хаяж хэд хэдэн сонголт байна: бүх өөрчлөлтүүд хийгдсэн, эсвэл хэсэгчлэн хийгдсэн (зарим объектын хувьд) эсвэл алдаа гарсан. Мөн хэд хэдэн стратеги байдаг: өөрчлөлтийг хүн бүрт амжилттай болсон тохиолдолд л хэрэгжүүлэх, эсвэл хэсэгчлэн хэрэглэх, эсвэл ямар нэгэн алдаа гарсан тохиолдолд буцаах, энэ нь гүйлгээний бүрэн механизмыг аль хэдийн татаж байна.

Төгс төгөлдөр болгохыг эрмэлздэг вэб API-ийн хувьд би ийм үйлдлүүдийг системд оруулахыг хүсч байна. Би үргэлжлэлүүдийн аль нэгэнд үүнийг хийхийг хичээх болно.

Статистикийн асуулга, нэгтгэгч, өгөгдөл форматлах

Сервер дээр хадгалагдсан өгөгдлүүд дээр үндэслэн бид статистикийн хураангуй эсвэл тусгай хэлбэрээр форматлагдсан өгөгдлийг авах шаардлагатай болдог: жишээлбэл, үйлчлүүлэгч тал дээр зураг зурах. Нэг ёсондоо энэ нь эрэлт хэрэгцээний дагуу, их бага хэмжээгээр, зөвхөн уншихад зориулагдсан өгөгдөл учраас үүнийг тусдаа ангилалд оруулах нь зүйтэй юм. Нэг нь өвөрмөц онцлогМиний бодлоор статистик нь тэд өвөрмөц үнэмлэхгүй гэсэн үг юм.

Бодит програмуудыг боловсруулахад энэ нь танд тохиолдож болох бүх зүйл биш гэдэгт би итгэлтэй байна, мөн таны нэмэлт, залруулгад баяртай байх болно.

Төрөл бүрийн өгөгдөл

Объектууд

Үйлчлүүлэгч болон серверийн хоорондох харилцааны гол өгөгдлийн төрөл нь объект юм. Үндсэндээ объект нь шинж чанаруудын жагсаалт ба тэдгээрийн харгалзах утгуудын жагсаалт юм. Бид хүсэлтээр сервер рүү объект илгээж, хүсэлтийн үр дүнг объект болгон авах боломжтой. Энэ тохиолдолд тухайн объект нь өгөгдлийн санд хадгалагдсан бодит объект байх албагүй, наад зах нь илгээсэн эсвэл хүлээн авсан хэлбэрээрээ. Жишээлбэл, зөвшөөрлийн итгэмжлэлүүдийг объект болгон дамжуулдаг боловч бие даасан байгууллага биш юм. Өгөгдлийн санд хадгалагдсан объектууд хүртэл өсөх хандлагатай байдаг нэмэлт шинж чанаруудсистем доторх шинж чанартай, жишээлбэл, үүсгэх, засварлах огноо, янз бүрийн системийн шошго, тугнууд. Объектийн шинж чанарууд нь өөрийн скаляр утгууд эсвэл агуулж болно холбогдох объектууд болон объектын цуглуулгууд, эдгээр нь объектын нэг хэсэг биш юм. Объектуудын зарим шинж чанарыг засварлах боломжтой, заримыг нь зөвхөн унших боломжтой, зарим нь статистик шинж чанартай бөгөөд шууд тооцоолдог (жишээлбэл, лайкны тоо). Хэрэглэгчийн эрхээс хамааран зарим объектын шинж чанарыг нууж болно.

Объектуудын цуглуулга

Цуглуулгын тухай ярихдаа бид нэгэн төрлийн объектуудын жагсаалттай ажиллах боломжийг олгодог серверийн нөөцийг хэлнэ. объект нэмэх, устгах, өөрчлөх, тэдгээрээс сонгох. Нэмж дурдахад, цуглуулга нь онолын хувьд өөрийн шинж чанартай (жишээлбэл, нэг хуудсанд байх хамгийн их элементийн тоо) болон функцтэй байж болно (энд би андуурч байна, гэхдээ энэ нь бас тохиолдсон).

Скаляр утгууд

Цэвэр хэлбэрээрээ скаляр утгууд нь тусдаа нэгж болох миний санах ойд маш ховор байсан. Тэдгээр нь ихэвчлэн объект эсвэл цуглуулгын шинж чанараар гарч ирдэг тул уншиж, бичиж болно. Жишээлбэл, хэрэглэгчийн нэрийг GET /users/1/name ашиглан тус тусад нь авч, өөрчлөх боломжтой. Практикт энэ функц ховорхон ашиг тустай боловч шаардлагатай бол би үүнийг гартаа байлгахыг хүсч байна. Энэ нь бичлэгийн тоо (шүүлттэй эсвэл шүүлтүүргүй) гэх мэт цуглуулгын шинж чанаруудад ялангуяа үнэн юм: GET /news/count .

Дараах нийтлэлүүдийн аль нэгэнд би эдгээр үйлдлүүдийг ангилж, практик дээр тааралдсан зүйл дээр үндэслэн боломжит хүсэлт, хариултын хувилбаруудыг санал болгохыг хичээх болно.

Хоёр дахь хандлага: Зөв арга зам

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

Далайн эрэг дээр зогсож байхдаа юу бодох хэрэгтэй вэ

Хувилбар хийх

Эрт орой хэзээ нэгэн цагт аливаа үйлдлийн систем хөгжиж эхэлдэг: хөгжиж, илүү төвөгтэй болж, цар хүрээтэй болж, шинэчлэгдэж эхэлдэг. REST API хөгжүүлэгчдийн хувьд энэ нь юуны түрүүнд хуучин хувилбарууд ажиллаж байх үед API-ийн шинэ хувилбаруудыг эхлүүлэх шаардлагатай болдогтой холбоотой юм. Энд би таны системийн бүрээсийн доорхи архитектурын өөрчлөлтийн тухай биш, харин өгөгдлийн формат өөрөө болон тэдгээртэй ажиллах үйлдлийн багц өөрчлөгдөж байгаа тухай ярьж байна. Ямар ч тохиолдолд эх кодын анхны зохион байгуулалт болон URL-г бүтээх зарчмын аль алинд нь хувилбар гаргах ёстой. URL хаягийн хувьд хүсэлтэд зориулагдсан API хувилбарыг тодорхойлох хамгийн түгээмэл хоёр арга байдаг. example-api.com/v1/ замыг угтвар болгож, v1.example-api.com дэд домайн түвшинд хувилбар хийх. Та тэдгээрийн аль нэгийг нь хэрэгцээ, хэрэгцээ шаардлагаас хамааран ашиглаж болно.

Бүрэлдэхүүн хэсгүүдийн бие даасан байдал

Олон хэрэглэгчийн үүргийг дэмждэг нарийн төвөгтэй системүүдийн Web API-г хэсэг болгон хуваах шаардлагатай байдаг бөгөөд тус бүр нь өөр өөр үүрэг даалгаврыг гүйцэтгэдэг. Үнэн хэрэгтээ хэсэг бүр нь өөр өөр физик машин, платформ дээр ажилладаг бие даасан програм байж болно. API тайлбарын хувьд сервер хүсэлтийг хэрхэн боловсруулж байгаа, үүнд ямар хүч, технологи оролцож байгаа нь бидэнд огт хамаагүй. API үйлчлүүлэгчийн хувьд систем нь бүрхэгдсэн байдаг. Гэсэн хэдий ч системийн өөр өөр хэсгүүд нь захиргааны болон хэрэглэгчийн хэсгүүд гэх мэт огт өөр функцтэй байж болно. Үүнтэй ижил төстэй ажиллах аргачлал нь нөөц нь эрс ялгаатай байж магадгүй юм. Иймд ийм хэсгүүдийг admin.v1.example-api.com домайн эсвэл example-api.com/v1/admin/ замын угтварын түвшинд тусгаарлах ёстой. Энэ шаардлага нь заавал байх албагүй бөгөөд системийн нарийн төвөгтэй байдал, зорилгоос ихээхэн хамаардаг.

Мэдээлэл солилцох формат

Хамгийн тохиромжтой, ажиллагаатай, миний бодлоор өгөгдөл солилцох формат бол JSON боловч XML, YAML эсвэл өгөгдлийн төрлийг алдалгүйгээр цуваажсан объектуудыг хадгалах боломжийг олгодог бусад форматыг ашиглахыг хэн ч хориглодоггүй. Хэрэв хүсвэл API дахь хэд хэдэн оролт / гаралтын форматыг дэмжих боломжтой. Хүссэн хариултын форматыг зөвшөөрөхийн тулд HTTP хүсэлтийн толгой хэсгийг ашиглахад хангалттай бөгөөд хүсэлтэд дамжуулагдсан өгөгдлийн форматыг зааж өгөхийн тулд Content-Type. Өөр нэг түгээмэл арга бол GET /users.xml гэх мэт нөөцийн URL-д өргөтгөл нэмэх боловч энэ нь URL-г илүү хүнд болгож, GET хүсэлтийн хувьд бүх зүйлээс илүү үнэн зөв учраас уян хатан биш, үзэсгэлэнтэй мэт санагддаг. боломжит үйлдлүүд.

Нутагшуулалт ба олон хэл

Практикт API олон хэл нь ихэвчлэн үйлчилгээний болон алдааны мэдэгдлийг эцсийн хэрэглэгчдэд шууд харуулахын тулд шаардлагатай хэл рүү хөрвүүлэхэд хүргэдэг. Олон хэл дээрх агуулга нь бас байх ёстой газартай боловч өөр өөр хэл дээр агуулгыг хадгалах, гаргах нь миний бодлоор илүү тодорхой ялгагдах ёстой, жишээлбэл, хэрэв та өөр хэл дээрх ижил нийтлэлтэй бол үнэн хэрэгтээ эдгээр нь өөр өөр хэлээр бүлэглэсэн хоёр өөр байгууллага юм. агуулгын нэгдлийн шинж тэмдгээр. Хүлээгдэж буй хэлийг тодорхойлохын тулд та ашиглаж болно янз бүрийн арга замууд. Хамгийн энгийн нь стандарт HTTP толгой нь Accept-Language юм. Би GET параметрийн хэл="en"-г нэмэх, example-api.com/en/ замын угтварыг ашиглах, эсвэл бүр en.example-api.com домэйн нэрийн түвшинд нэмэх гэх мэт өөр аргуудыг харсан. Орон нутгийн тохиргоог хэрхэн сонгох нь тухайн програм болон түүнд тулгарч буй ажлуудаас хамаарна гэж надад санагдаж байна.

Дотоод чиглүүлэлт

Тиймээс бид API (эсвэл түүний бүрэлдэхүүн хэсгүүдийн нэг)-ийн үндсэн зангилаа руу орлоо. Цаашдын бүх чиглүүлэлтүүд таны серверийн программ дотор, түүний дэмждэг нөөцийн дагуу шууд дамжих болно.

Цуглуулгын замууд

Цуглуулгын замыг зааж өгөхийн тулд бид зүгээр л харгалзах байгууллагын нэрийг ашиглана, жишээлбэл, хэрэв энэ нь хэрэглэгчдийн жагсаалт бол зам нь /users . Цуглуулгад хоёр аргыг хэрэглэж болно: GET (хязгаарлагдмал байгууллагуудын жагсаалтыг авах) ба POST (шинэ элемент үүсгэх). Бид жагсаалт авах хүсэлтэд олон тооны нэмэлт GET параметрүүдийг ашиглаж болох бөгөөд пейжинг, эрэмбэлэх, шүүх, хайх гэх мэт үйлдлүүдэд ашигладаг, гэхдээ тэдгээр нь сонголттой байх ёстой. Эдгээр параметрүүдийг замын нэг хэсэг болгон дамжуулж болохгүй!

Цуглуулгын элементүүд

Цуглуулгын тодорхой элементэд хандахын тулд бид замдаа түүний өвөрмөц танигч /хэрэглэгч/25-ыг ашигладаг. Энэ бол түүнд хүрэх өвөрмөц зам юм. Объекттой ажиллахын тулд GET (объект авах), PUT / PATCH (өөрчлөх) болон DELETE (устгах) аргуудыг хэрэглэнэ.

Өвөрмөц объектууд

Олон үйлчилгээнд одоогийн хэрэглэгчийн профайл /профайл эсвэл хувийн тохиргоо /тохиргоо гэх мэт одоогийн хэрэглэгчдэд өвөрмөц объектууд байдаг. Мэдээжийн хэрэг, эдгээр нь нэг талаараа цуглуулгуудын аль нэгнийх нь элементүүд боловч эдгээр нь манай Вэб API-г үйлчлүүлэгчийн програмаар ашиглах эхлэлийн цэг бөгөөд үүнээс гадна илүү их зүйлийг зөвшөөрдөг. өргөн хамрах хүрээөгөгдөл дээрх үйлдлүүд. Үүний зэрэгцээ, хэрэглэгчийн тохиргоог хадгалдаг цуглуулга нь аюулгүй байдал, мэдээллийн нууцлалын шалтгаанаар огт боломжгүй байж магадгүй юм.

Объект ба цуглуулгын шинж чанарууд

Объектын аль нэг шинж чанарт шууд хандахын тулд тухайн объект руу очих замд тухайн өмчийн нэрийг нэмэхэд хангалттай, жишээлбэл, хэрэглэгчийн нэрийг /users/25/name авна. GET (утга авах) болон PUT/PATCH (утга өөрчлөх) аргууд нь үл хөдлөх хөрөнгөд хамааралтай. DELETE аргыг ашиглах боломжгүй, учир нь шинж чанар нь өгөгдлийн албан ёсны нэгжийн хувьд объектын бүтцийн хэсэг юм.

Өмнөх хэсэгт бид цуглуулгууд нь объектын нэгэн адил өөрийн гэсэн шинж чанартай байж болох талаар ярилцсан. Миний санах ойд зөвхөн count шинж чанар надад хэрэгтэй байсан ч таны програм илүү төвөгтэй, тодорхой байж болно. Цуглуулгын шинж чанаруудад хүрэх замыг тэдгээрийн элементүүдийн шинж чанаруудтай ижил зарчмын дагуу бүтээдэг: /users/count . Цуглуулгын шинж чанаруудын хувьд зөвхөн GET аргыг (хөрөнгө олж авах) хэрэглэнэ. Цуглуулга нь жагсаалтад хандах энгийн интерфейс юм.

Холбогдох объектуудын цуглуулга

Нэг төрлийн объектын шинж чанарууд нь холбогдох объектууд эсвэл холбогдох объектуудын цуглуулга байж болно. Дүрмээр бол ийм аж ахуйн нэгжүүд нь тухайн объектын өөрийн өмч биш бөгөөд зөвхөн бусад аж ахуйн нэгжүүдтэй харилцах харилцааг илэрхийлдэг. Жишээлбэл, хэрэглэгч /users/25/roles-д хуваарилагдсан үүргүүдийн жагсаалт. Бид дараах хэсгүүдийн аль нэгэнд үүрлэсэн объект, цуглуулгатай ажиллах талаар дэлгэрэнгүй ярих болно, гэхдээ энэ үе шатанд объектын бусад өмчийн нэгэн адил тэдгээрт шууд хандах нь бидэнд хангалттай юм.

Объект ба цуглуулгын функцууд

Цуглуулга эсвэл объект дээр функц дуудлагын интерфэйсийн замыг бий болгохын тулд бид өмч рүү хандахтай ижил аргыг ашигладаг. Жишээлбэл, /users/25/sendPasswordReminder объект эсвэл /users/disableUnconfirmed цуглуулгын хувьд. Функцын дуудлагын хувьд бид ямар ч байсан POST аргыг ашигладаг. Яагаад? Сонгодог REST-д функцийг дуудах тусгай үйл үг байдаггүй тул одоо байгаа аль нэгийг нь ашиглах хэрэгтэй болно гэдгийг сануулъя. Миний бодлоор үүнд POST арга хамгийн тохиромжтой. Энэ нь танд шаардлагатай аргументуудыг сервер рүү дамжуулах боломжийг олгодог, idempotent биш (олон удаа хандсан үед ижил үр дүнг буцаадаг), семантикийн хамгийн хийсвэр юм.

Бүх зүйл системд их бага хэмжээгээр нийцдэг гэж найдаж байна 🙂 Дараагийн хэсэгт бид хүсэлт, хариулт, тэдгээрийн формат, статус кодын талаар илүү дэлгэрэнгүй ярих болно.

Гурав дахь хандлага: Хүсэлт ба хариулт

Өмнөх тооцоололд би одоо байгаа туршлагыг цуглуулж, нэгтгэх санаа хэрхэн үүссэн талаар ярьсан вэб хөгжүүлэлт API. Эхний хэсэгт би вэб API зохиохдоо ямар төрлийн нөөцүүд, тэдгээрт хамаарах үйлдлүүдтэй холбоотой болохыг тайлбарлахыг оролдсон. Хоёрдахь хэсэг нь эдгээр нөөцөд хандах өвөрмөц URL-уудыг бий болгох асуудлыг хөндсөн. Мөн энэ ойролцоо байдлаар би хүсэлт, хариултын боломжит хувилбаруудыг тайлбарлахыг хичээх болно.

Бүх нийтийн хариулт

Сервер ба үйлчлүүлэгчийн хоорондох харилцааны тодорхой хэлбэр нь хөгжүүлэгчийн үзэмжээр ямар ч байж болно гэж бид аль хэдийн хэлсэн. Миний хувьд хамгийн тохиромжтой, харагдахуйц юм шиг санагддаг JSON формат, хэдийгээр бодит програм нь олон форматыг дэмждэг байж болох юм. Одоохондоо хариултын объектын бүтэц, шаардлагатай шинж чанарууд дээр анхаарлаа хандуулцгаая. Тийм ээ, бид серверээс буцаасан бүх өгөгдлийг тусгай саванд боож өгнө - ерөнхий хариултын объект, энэ нь цаашдын боловсруулалтанд шаардлагатай бүх үйлчилгээний мэдээллийг агуулсан болно. Тэгэхээр энэ мэдээлэл юу вэ:

Амжилт - хүсэлтийн амжилтын тэмдэг

Серверээс хариу хүлээн авахдаа хүсэлт амжилттай болсон эсэхийг нэн даруй ойлгож, зохих зохицуулагч руу шилжүүлэхийн тулд "амжилт" амжилтын тэмдэглэгээг ашиглахад хангалттай. Ямар ч өгөгдөл агуулаагүй серверийн хамгийн энгийн хариулт дараах байдалтай байна.

POST /api/v1/articles/22/publish ( "амжилт": үнэн )

Алдаа - алдааны тухай мэдээлэл

Хэрэв хүсэлт бүтэлгүйтвэл - бид серверийн сөрөг хариултын шалтгаан, төрлүүдийн талаар бага зэрэг ярих болно - HTTP төлөвийн код болон алдааны мессежийн текстийг агуулсан "алдаа" шинж чанарыг хариуд нэмж оруулсан болно. тухай мессежтэй андуурч болохгүй баталгаажуулалтын алдаатодорхой талбарт зориулсан өгөгдөл. Хариултын толгой хэсэгт статусын кодыг буцаах нь миний бодлоор хамгийн зөв юм, гэхдээ би бас өөр арга барилтай таарсан - толгой хэсэгт 200 (амжилт) статусыг үргэлж буцааж, хариултын хэсэгт дэлгэрэнгүй мэдээлэл болон алдааны мэдээллийг илгээдэг.

GET /api/v1/user ( "амжилт": худал, "алдаа": ( "код": 401, "мессеж": "Зөвшөөрөл амжилтгүй боллоо") )

Өгөгдөл - серверээс буцаасан өгөгдөл

Ихэнх серверийн хариултууд нь өгөгдлийг буцаахад зориулагдсан байдаг. Хүсэлтийн төрөл болон түүний амжилтаас хамааран хүлээгдэж буй өгөгдлийн багц өөр байх боловч хариултын дийлэнх хэсэгт "өгөгдлийн" шинж чанар байх болно.

Амжилттай буцаж ирсэн өгөгдлийн жишээ. Энэ тохиолдолд хариулт нь хүссэн хэрэглэгчийн объектыг агуулна.

GET /api/v1/user ( "амжилт": үнэн, "өгөгдөл": ( "id" : 125, "имэйл" : " [имэйлээр хамгаалагдсан]", "нэр" : "Жон", "овог" : "Смит", ) )

Алдаа гарсан тохиолдолд буцаасан өгөгдлийн жишээ. Энэ тохиолдолд талбарын нэр болон баталгаажуулалтын алдааны мэдэгдлүүдийг агуулна.

PUT /api/v1/user ( "амжилт": худал, "алдаа": ( "код" : 422, "мессеж": "Баталгаажуулалт амжилтгүй болсон" ) "өгөгдөл": ( "имэйл" : "Имэйл хоосон байж болохгүй. ",))

Pagination - хуудаслах ажлыг зохион байгуулахад шаардлагатай мэдээлэл

Бодит өгөгдлөөс гадна буцаж ирдэг хариултуудад цуглуулгын элементүүдийн багц, асуулгын үр дүнд тулгуурлан хуудасны тухай мэдээлэл байх ёстой.

Хуудасчлах утгын хамгийн бага багц нь дараахь зүйлээс бүрдэнэ.

• нийт бичлэгийн тоо;
• хуудасны тоо;
• одоогийн хуудасны дугаар;
• хуудас бүрт байгаа бичлэгийн тоо;
• серверийн талаас дэмждэг хуудсанд ногдох хамгийн их бичлэгийн тоо.

Зарим вэб API хөгжүүлэгчид хөрш зэргэлдээ хуудсууд руу орох бэлэн холбоосууд болон эхний, сүүлчийн, одоогийн хуудсуудыг хуудсууд руу оруулдаг.

GET /api/v1/articles Хариулт: ( "амжилт": үнэн, "өгөгдөл": [ ( "id" : 1, "гарчиг" : "Сонирхолтой зүйл", ), ( "id" : 2, "гарчиг" : "Уйтгартай текст", ) ], "хуудас": ( "totalRecords" : 2, "totalPages" : 1, "currentPage" : 1, "perPage" : 20, "maxPerPage" : 100, ) )

Алдаа дээр ажиллах

Дээр дурдсанчлан вэб API-д өгсөн бүх хүсэлтүүд амжилтанд хүрч чаддаггүй, гэхдээ энэ нь бас тоглоомын нэг хэсэг юм. Алдаа мэдээлэх систем нь үйлчлүүлэгчийн ажлыг хөнгөвчлөх, үйлчлүүлэгчийн програмыг зөв замд чиглүүлэх хүчирхэг хэрэгсэл юм. Энэ агуулгад "алдаа" гэсэн үг бүрэн тохирохгүй байна. Энэ үг энд илүү тохиромжтой. үл хамаарах зүйл, үнэндээ хүсэлтийг амжилттай хүлээн авч, задлан шинжилж, зохих хариуг буцааж өгсөн тул хүсэлтийг яагаад биелүүлэх боломжгүй байгааг тайлбарлав.

Таны олж авсан үл хамаарах зүйлүүдийн боломжит шалтгаанууд юу вэ?

500 Дотоод серверийн алдаа - бүх зүйл эвдэрсэн, гэхдээ бид удахгүй засах болно

Асуудал нь серверийн хажуу талд гарсан тохиолдолд яг ийм тохиолдол гардаг бөгөөд клиент програм нь зөвхөн санаа алдаж, сервер ядарч, хэвтэхийг мэдэгдэнэ. Жишээлбэл, мэдээллийн сантай холболт тасарсан эсвэл кодонд алдаа гарсан.

400 Буруу хүсэлт - одоо бүх зүйл эвдэрсэн

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

401 Зөвшөөрөгдөөгүй - танихгүй хүн, өөрийгөө таниул

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

403 Хориотой - чи энд ирж болохгүй

Хүссэн нөөц байгаа боловч хэрэглэгч үүнийг харах, өөрчлөх хангалттай эрхгүй.

404 Олдсонгүй - энэ хаяг дээр хэн ч амьдардаггүй

Дүрмээр бол ийм хариуг гурван тохиолдолд буцаана: нөөцөд хүрэх зам буруу (алдаатай), хүссэн нөөцийг устгаж, оршин тогтнохоо больсон, одоогийн хэрэглэгчийн эрх нь оршин байгаа байдлын талаар мэдэхийг зөвшөөрдөггүй. хүссэн нөөцийн. Тухайлбал, бараа бүтээгдэхүүний жагсаалтыг үзэж байтал нэг нь гэнэт моодноос гарч, хасагдсан байна.

405 аргыг зөвшөөрөхгүй

Энэ төрлийн үл хамаарах зүйл нь хүсэлтэд ашигласан үйл үгтэй шууд холбоотой (GET, PUT, POST, DELETE) бөгөөд энэ нь эргээд бидний нөөцөөр хийх гэж буй үйлдлийг илэрхийлдэг. Хэрэв хүссэн нөөц нь заасан үйлдлийг дэмжихгүй бол сервер шууд хэлнэ.

422 Боловсруулах боломжгүй байгууллага - засаад дахин илгээнэ үү

Хамгийн ашигтай үл хамаарах зүйлүүдийн нэг. Хүсэлтийн өгөгдөлд логик алдаа гарсан тохиолдолд буцаана. Хүсэлтийн өгөгдөл гэж бид GET аргаар дамжуулсан параметрийн багц ба тэдгээрийн харгалзах утгуудыг эсвэл POST, PUT, DELETE аргуудаар хүсэлтийн биед дамжуулагдсан объектын талбаруудыг хэлнэ. Хэрэв өгөгдөл баталгаажаагүй бол "өгөгдөл" хэсэгт байгаа сервер ямар параметрүүд хүчингүй болсон, яагаад гэсэн тайланг буцаана.

HTTP протокол нь маш их дэмждэг илүүбүх тохиолдлуудад зориулсан янз бүрийн статус кодууд байдаг боловч практикт тэдгээрийг бараг ашигладаггүй бөгөөд вэб API-ийн хүрээнд ямар ч практик хэрэглээгүй байдаг. Миний санах ойд би дээрх үл хамаарах зүйлүүдийн жагсаалтаас цааш явах шаардлагагүй байсан.

Хүсэлтүүд

Цуглуулгын элементүүдийг олж авах

Хамгийн их ирдэг хүсэлтүүдийн нэг бол цуглуулгын элементүүдийг авах хүсэлт юм. Мэдээллийн хангамж, бүтээгдэхүүний жагсаалт, төрөл бүрийн мэдээлэл, статистикийн хүснэгтүүд болон бусад зүйлсийг цуглуулгын нөөцөд хандах замаар үйлчлүүлэгчийн аппликейшн харуулдаг. Энэ хүсэлтийг гаргахын тулд бид GET аргыг ашиглан цуглуулга руу хандаж, асуулгын мөрөнд нэмэлт параметрүүдийг дамжуулдаг. Бид дээр дурьдсанчлан, хариултын хувьд бид цуглуулгын нэг төрлийн элементүүдийн массив, хуудсыг хуудасжуулахад шаардлагатай мэдээллийг хүлээн авах болно - жагсаалтын үргэлжлэл эсвэл түүний тодорхой хуудсыг ачаалах. Сонгон шалгаруулалтын агуулгыг тусгай аргаар хязгаарлаж, дамжуулж эрэмбэлж болно нэмэлт сонголтууд. Тэдгээрийг цаашид хэлэлцэх болно.

Хуудсууд

хуудас- параметр нь аль хуудсыг харуулахыг заана. Хэрэв энэ параметрийг дамжуулаагүй бол эхний хуудас гарч ирнэ. Эхний амжилттай серверийн хариултаас эхлэн цуглуулга нь одоогийн шүүлтүүрийн параметрүүдтэй хэдэн хуудастай болох нь тодорхой болно. Хэрэв утга нь хуудасны дээд хэмжээнээс хэтэрсэн бол алдаа буцаах нь хамгийн үндэслэлтэй юм 404 Олдсонгүй.

/api/v1/news?page=1 АВАХ

нэг хуудас- хуудас бүрт хүссэн элементийн тоог заана. Ерөнхийдөө API нь хуудасны хэсэг дэх perPage талбарыг буцаадаг өөрийн гэсэн өгөгдмөл утгатай байдаг боловч зарим тохиолдолд энэ нь maxPerPage-ийн дээд утгыг өгөх замаар энэ утгыг боломжийн хязгаар хүртэл нэмэгдүүлэх боломжийг олгодог:

/api/v1/news?perPage=100 АВАХ

Үр дүнг эрэмбэлэх

Ихэнхдээ сонголтын үр дүнг харьцуулсан (тоон талбарын хувьд) эсвэл цагаан толгойн (мөр талбарын хувьд) эрэмбэлэхийг дэмждэг тодорхой талбаруудын утгуудаар өсөх эсвэл буурах дарааллаар эрэмбэлэх шаардлагатай байдаг. Жишээлбэл, бид хэрэглэгчдийн жагсаалтыг нэрээр нь эсвэл үнээр нь эрэмбэлэх хэрэгтэй. Нэмж дурдахад бид А-аас Я хүртэл эсвэл эсрэг чиглэлд эрэмбэлэх чиглэлийг тохируулах боломжтой бөгөөд өөр өөр талбарт өөр өөр байна.

эрэмбэлэх- GET параметрт цогц эрэмбэлэх тухай өгөгдлийг дамжуулах хэд хэдэн арга байдаг. Энд та эрэмбэлэх дараалал, чиглэлийг тодорхой зааж өгөх хэрэгтэй.

Зарим API үүнийг мөр болгон хийхийг санал болгож байна:

/api/v1/products?sortBy=name.desc,price.asc АВАХ

Бусад сонголтууд нь массив ашиглахыг санал болгож байна:

/api/v1/бүтээгдэхүүнийг АВАХ уу? sortBy=name& sortBy=desc& sortBy=price& sortBy=usc

Ерөнхийдөө ижил зааврыг дамжуулдаг тул хоёр сонголт хоёулаа тэнцүү байна. Миний бодлоор массив бүхий сонголт нь илүү уян хатан байдаг, гэхдээ энд тэдний хэлснээр амт, өнгө ...

Утгаар нь энгийн шүүлт

Сонголтыг талбарын утгаар шүүхийн тулд ихэнх тохиолдолд талбарын нэр болон шаардлагатай утгыг шүүлтүүрийн параметр болгон дамжуулахад хангалттай. Жишээлбэл, бид нийтлэлийг зохиогчийн дугаараар шүүхийг хүсэж байна:

/api/v1/articles?authorId=25 АВАХ

Нарийн шүүлтүүрийн сонголтууд

Олон интерфэйсүүд нь илүү төвөгтэй шүүлтүүр, хайлтын системийг шаарддаг. Би шүүлтүүрийн үндсэн ба хамгийн түгээмэл сонголтуудыг жагсаах болно.

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

/api/v1/products?price=500&price=1000 АВАХ

Жагсаалтаас олон боломжит утгуудаар шүүж байна. Талбайд хэрэглэсэн, тохируулсан боломжит утгуудЭнэ нь жишээлбэл, шүүлтүүрийг хэд хэдэн статусаар хязгаарладаг:

/api/v1/products?status=1&status=2 АВАХ

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

GET /api/v1/users?name=John GET /api/v1/products?code=123

Нэрлэсэн шүүлтүүрүүд

Зарим тохиолдолд шүүлтүүрийн параметрүүдийн тодорхой багцыг ихэвчлэн ашигладаг бөгөөд систем нь салшгүй зүйл гэж ойлгодог, ялангуяа түүвэрлэлтийн дотоод, ихэвчлэн нарийн төвөгтэй механикт нөлөөлдөг бол тэдгээрийг шүүлтүүр гэж нэрлэгддэг шүүлтүүр болгон бүлэглэхийг зөвлөж байна. Хүсэлтэд шүүлтүүрийн нэрийг оруулахад хангалттай бөгөөд систем автоматаар сонголтыг хийх болно.

/api/v1/products?filters=зөвлөдөг

Нэрлэсэн шүүлтүүрүүд нь мөн өөрийн гэсэн параметртэй байж болно.

/api/v1/products?filters=kidds

Энэ дэд хэсэгт би хамгийн алдартай сонголтууд болон шаардлагатай дээжийг олж авах арга замын талаар ярихыг оролдсон. Таны практикт энэ сэдэвтэй холбоотой олон жишээ, нарийн ширийн зүйлс байх болно. Хэрэв танд миний материалд нэмэх зүйл байвал би зөвхөн баяртай байх болно. Энэ хооронд нийтлэл аль хэдийн том хэмжээтэй болсон тул бид дараагийн тооцоололд бусад төрлийн хүсэлтийг шинжлэх болно.

6.1 Хэмжээг шалгах арга

Синтакс:

Булийн Хэмжээг шалгах(Хэмжээний хэмжээсийн жагсаалт,

Гүйлтийн урт,

Хөрвүүлэх өргөн,

Хөвөгч өндөр,

Гадагш жин,

Гадны тайлбар)

Сонголтууд:

Параметрийн нэр	Оролт гаралт	Төрөл	Тодорхойлолт
Хэмжээний жагсаалт	оролт	Хэмжээ	массив нийт жин бүтээгдэхүүний шинж чанар
Урт	амралтын өдөр	хөвөх	Илгээмжийн урт
Өргөн	амралтын өдөр	хөвөх	Илгээмжийн өргөн
Өндөр	амралтын өдөр	хөвөх	Илгээмжийн өндөр
Жин	амралтын өдөр	хөвөх	Илгээмжийн жин
Сэтгэгдэл	амралтын өдөр	хөвөх	Хэт хэтэрсэн тохиолдолд текстийн тайлбар нийт жингийн хязгаарын утгууд шинж чанарууд

Тодорхойлолт:

Бүх барааны жин, хэмжээний шинж чанарын жагсаалтыг аргад шилжүүлнэ
(Хэмжээний жагсаалт). Тооцооллын дараа гаралтын параметрүүд Урт, Өргөн, Өндөр (урт,
өргөн ба өндрийг тус тусад нь шийдвэрлэсний дараа илгээмжийн хэмжээсээр бөглөнө
асуудал "оновчтой овоолох" болон параметр Жин дамжуулсан бүх нийт жин
сав баглаа боодлын материалаас бусад бараа. Тухайн тохиолдолд ачааны хэмжээ
хязгаарын утгаас хэтэрсэн тохиолдолд тайлбарын параметрт текстийн тайлбар дамжуулагдана
үл нийцэх байдал.

Буцах утга:Арга нь Boolean True if буцаана
нийт жингийн шинж чанар нь хязгаарлагдмал утга ба хүргэлтээс хэтрэхгүй
дор хаяж нэг боломжтой хүртээмжтэй арга, эс бөгөөс Худал. Өгсөн байх магадлалтай
Энэ аргыг үйлчлүүлэгчийн талд онлайн үнэлгээнд ашиглаж болно
захиалга илгээх, аливааг цаг тухайд нь хүлээн авах үндсэн боломж
боломжгүй бол шийдвэр гаргах.

6.1.1 CheckDimensions аргыг дуудах жишээ

// Сагсанд 2 байрлал байгаа бөгөөд хэтэрсэн эсэхийг шалгах хэрэгтэй гэж бодъё
зөвшөөрөгдөх хэмжээ, жингийн хязгаарлалт
aplix.Dimensions Dimensions = шинэ aplix.Dimensions;
aplix.DimensionsItem;

Урт = 0.130f;
Item.Width = 0.100f;
Item.Height = 0.001f;
Зүйл.Жин = 0.1f;
Item.Qty = 2;
Хэмжээ = зүйл;
Item = new aplix.Dimensions();
Item.Length = 0.1331f;
Item.Width = 0.0998f;
Item.Height = 0.0788f;
Item.Weight = 0.575f;
Item.Qty = 1;
Хэмжээ = зүйл;
// Гаралтын параметрүүд
хөвөх урт;
хөвөх өргөн;
хөвөх өндөр;
хөвөх жин;
мөр тайлбар;
// Жин шалгах
bool Үр дүн = ws.CheckDimenshions(Хэмжээ, урт урт, өргөн өргөн, өндөр, жин, гадуур Тайлбар);
// Үр дүнгийн дүрслэл
Response.Write("Үр дүн: " + Үр дүн.ToString() + "");
Response.Write("Урт: " + Length.ToString() + "");
Response.Write("Өргөн: " + Width.ToString() + "");
Response.Write("Өндөр: " + Height.ToString() + "");
Response.Write("Жин: " + Weight.ToString() + "");
Response.Write("Жин: "+Сэтгэгдэл+"");

6.2 Тээвэрлэлтийн зардлыг тооцоолох арга

Синтакс:
Урт Тээвэрлэлтийн зардлыг тооцоолох(мөр захиалгын дугаар,
float зарласан зардал,
Бараа бараа,
Хаяг,
Byte TypeOfSeal,
Boolean бат бөх савлагаа,
Boolean CashOn Delivery,
Хүргэлтийн төрөл,
Out string Comments) Параметрүүд:

Параметрийн нэр	Оролт гаралт	Төрөл	Тодорхойлолт
Захиалгын дугаар	оролт	мөр	Системд мэдэгдэж байгаа бол захиалгын дугаар хэрэглэгч. Хэрэв өгсөн бол тооцоолол ирээдүйд захиалгатай холбоотой байх болно.
зарласан зардал	оролт	хөвөх	Ачааны зарласан үнэ. Дээр даатгал.
Бараа	оролт	Бараа	Бараа бүтээгдэхүүний жагсаалт бүтэц (Худалдагчийн код, нэр, Урт, Өргөн, өндөр, жин, тоо хэмжээ)
Хаяг	оролт	Хаяг	Хүлээн авагчийн хаяг (бүтэц: Шуудангийн индекс, бүс нутаг, Талбай, хот, Орон нутаг, гудамж, байшин, орон сууц, Картира)
TypeOfSeal	оролт	байт	Сонголт лац, боломжтой утга: 1 Шаардлагагүй 2 Бөмбөлөг боолт 3 дүүргэгч
Sturdy Packagin	оролт	Булийн	Энэ нь хатуу байх шаардлагатай юу багц
Бэлэн мөнгө Хүргэлт	оролт	Булийн	Хүргэлтийн үед бэлэн мөнгө шаардлагатай юу
төрөл	амралтын өдөр	Хүргэлтийн төрөл
Сэтгэгдэл	амралтын өдөр	Хүргэлтийн төрөл	Боломжтой тээврийн сонголтуудын жагсаалт

Тодорхойлолт:

Өгөгдсөн параметрүүд дээр үндэслэн арга нь боломжтой хүргэх сонголтуудын жагсаалтыг буцаана
(гаралтын параметрийн төрөл) бүтцийн массив хэлбэрээр<Идентификатор способа доставки, Наименование способа доставки, Себестоимость доставки, Страховую премию, Затраты на упаковку и маркировку, Адрес нахождения почтового отделения, либо точки самовывоза, Режим работы почтового отделения, либо точки самовывоза, Минимальное количество дней доставки, Максимальное количество дней доставки, Доп.информация>. Тооцооллын явцад үл хамаарах зүйл байвал
алдааны тайлбарыг Сэтгэгдэл параметрт буцаана.

Буцах утга:

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

6.2.1 CalculateShippingCost аргыг дуудах жишээ

ws.Credentials = шинэ NetworkCredential("туршилт", "туршилт");


Address.Index = "684005";


Хаяг.Хот = "Елизово хот";

Address.Home = "16";


aplix.GoodsItem;
Item = new aplix.Goods();
Item.SKU = "216293";

Урт = 0.130f;
Item.Width = 0.100f;
Item.Height = 0.001f;
Зүйл.Жин = 0.1f;
Item.Qty = 2;
Бараа = зүйл;
Item = new aplix.Goods();
Item.SKU = "499687";

Item.Length = 0.1331f;
Item.Width = 0.0998f;
Item.Height = 0.0788f;
Item.Weight = 0.575f;
Item.Qty = 1;
Бараа = зүйл;
//Тооцооны машинд зориулсан параметрүүдийг бөглөнө үү
stringOrderNumber="1234567890";
float DeclaredCost = 36370;
sbyte TypeOfSeal = 1;
bool SturdyPackaging = үнэн;
bool CashOnDelivery = худал;
aplix.DeliveryType төрлүүд; мөрийн тайлбар;
// тооцоолуурын дуудлага
long Status = ws.CalculateShippingCost(OrderNumber, DeclaredCost, Бараа, Хаяг,TypeOfSeal, Sturdy Packaging,CashOn Delivery, out Types, out Comments);
//Үр дүнгийн дүрслэл
Response.Write("Тооцооны ID: "+Status.ToString()+"
");
Response.Write("Тооцооллын талаарх нэмэлт мэдээлэл: " + Сэтгэгдэл + "
");
Хариулах.Бичих(@"
");
foreach (төрөл дэх aplix.DeliveryType төрөл) (
Хариулах.Бичих(""+ " "+ " "+ " " + " " + " " + " " + " " + " " + " + " " + " " + " " + " "); )
Хариулах.Бичих("

TypeId	TypeName	Тайлбарын төрөл	зардал	Даатгал	Шуудангийн үнэ	бэлтгэх зардал	Хаяг	Ажлын цаг	Хамгийн бага хугацаа	Хамгийн их хугацаа	Нэмэлт мэдээлэл
" + type.TypeId.ToString() + "	" + type.TypeName + "	" + type.TypeDescription + "	" + type.Cost.ToString() + "	" + type.Insurance.ToString() + "	" + type.PostalRate.ToString() + "	" + type.PreparingCost.ToString() + "	" + төрөл. Хаяг + "	" + бичнэ үү. Ажлын цаг + "	" + type.MinPeriod.ToString() + "	" + type.MaxPeriod.ToString() + "	" + type. Нэмэлт мэдээлэл + "

");

 } 


6.3 PushOrder арга
Синтакс: 
Урт түлхэх захиалга(
ID, 
тоо, 
огноо, 
үйлчлүүлэгч, 
зарласан зардал, 
төлсөн дүн, 
DeliveryTypeId, 
Төрөл Offseal, 
Бат бөх савлагаа, 
үйл ажиллагаа, 
бараа, 
хүргэлтийн өдөр, 
StartTime Delivery, 
Эцсийн цаг хүргэлт, 
сэтгэгдэл, 
тээвэрлэгч, 
тэмдэглэгээ) 
Сонголтууд:
Параметрийн нэр
Оролт гаралт
Төрөл
Тодорхойлолт
ID
оролт
Мөр
Систем дэх захиалгын ID 
хэрэглэгч ( өвөрмөц үнэ цэнэ)

тоо
оролт
Мөр
Хэрэглэгчийн систем дэх захиалгын дугаар 
(сэтгэгдэл дээр хэвлэгдэх болно) 
ачааг тэмдэглэх үед)
Огноо
оролт
он сар өдөр цаг
Хэрэглэгчийн систем дэх захиалгын огноо (болно 
сэтгэгдэл дээр хэвлэх 
ачааны тэмдэглэгээ
үйлчлүүлэгч
оролт
үйлчлүүлэгч
Худалдан авагчийн мэдээлэл, бүтэц 

зарласан зардал
оролт
хөвөх
Ачааны зарласан үнэ.  Дээр 
заасан хэмжээгээр олгоно 
даатгал.
ToBeP 
тусламж
оролт
хөвөх
нийлбэр 
руу 
төлбөр. 
Хэрвээ 
захиалга 
урьдчилгаа төлбөр дараа нь 0.
DeliveryTypeId
оролт
int
Сонгосон аргын ID 
хүргэлт.
TypeOfSeal
оролт
int
Сонголт 
лац, 
боломжтой 
үнэ цэнэ: 
1 Шаардлагагүй 
2 Бөмбөлөг боолт 
3 дүүргэгч
Бат бөх савлагаа
оролт
Булийн
Энэ нь хатуу байх шаардлагатай юу 
багц
Үйл ажиллагаа
оролт
Булийн
Захиалгын хамаарал.  Үнэн - хэрэв захиалга байвал 
хүчинтэй, Худал - захиалга цуцлагдсан тохиолдолд.
Бараа
оролт
Бараа
Бүтээгдэхүүний жагсаалт
Хүргэлтийн өдөр
оролт
он сар өдөр цаг
Хүргэлтийн огноо, сонгосон бол бөглөнө үү 
Шуурхай Хүргэлт
StartTimeDeliv 
ery
оролт
int
Хүслийн жагсаалт 
цаг 
хүргэлт 
"FROM", 

хүргэлт
Төгсгөлийн цаг
оролт
int
Хүссэн хүргэх хугацаа "Хүртэл", 
шуудан зөөгч сонгосон бол бөглөнө үү 
хүргэлт
Сэтгэгдэл
оролт
Мөр
Захиалга дээр сэтгэгдэл бичээрэй
Тээвэрлэгчийн дугаар
оролт
Мөр
Тодорхойлогч 
илгээгч, 
дүүрсэн байна 
хэрэв 
эсрэг тал дээр 
хэд хэдэн онлайн дэлгүүрүүд
тэмдэглэгээ
оролт
Мөр
Захиалгын тэмдэглэгээ, хэрэв бөглөсөн бол 
тээвэрлэлтүүд шошготой байна 
вэб сайт
Тодорхойлолт:
Энэ арга нь гүйцэтгэгчийн системд захиалгын талаарх мэдээллийг байрлуулдаг.  системийн хэрэглэгч 
захиалгын дугаар, огноо, захиалгын өвөрмөц танигч, тухай мэдээллийг дамжуулдаг 
хүлээн авагч, түүний хаяг, утасны дугаар, зарласан үнэ цэнэ, ногдуулсан хэмжээ 
төлбөр, хэрэв байгаа бол, барааны хавсралтын найрлага, савлагааны төрөл, сонгосон 
хүргэх арга, дэлгэрэнгүй мэдээлэл.
Буцах утга:
Энэ арга нь гүйцэтгэгчийн систем дэх өвөрмөц захиалгын тодорхойлогчийг буцаана.
6.3.1 PushOrder аргыг дуудах жишээ

aplix.Delivery ws = шинэ aplix.Delivery(); 
ws.Credentials = шинэ NetworkCredential("туршилт", "туршилт"); 
// "Хүлээн авагчийг илгээх" бүтцийг бэлтгэ 
aplix.Customer = шинэ aplix.Customer(); 

 // 684005, Камчаткийн хязгаар, Елизовский дүүрэг, Елизово хот, Ленинская гудамж, 16-р байшин 
aplix.Address Address = new aplix.Address(); 
Address.Index = "684005"; 
Address.Region = "Камчатскийн хязгаар"; 
Хаяг.Дүүрэг = "Елизовский дүүрэг"; 
Хаяг.Хот = "Елизово хот"; 
Хаяг.Гудамж = "Ленинская гудамж"; 
Address.Home = "16"; 
Customer.Address = Хаяг; 
Customer.ID = " [имэйлээр хамгаалагдсан]";
Customer.Name = "Сергей"; 
Customer.Email = " [имэйлээр хамгаалагдсан]";
Customer.Phone = "+7(916)975-53-54"; 
//Захиалгын параметрүүдийг бөглөнө үү 
string ID = "2013-1234567890";  // Үйлчлүүлэгчийн систем дэх захиалгын өвөрмөц танигч 
string Number = "1234567890";  // Харилцагчийн систем дэх захиалгын дугаар 
DateTime Date = шинэ DateTime(2013, 08, 30); 
float DeclaredCost = 36350.0f;  // Зарлагдсан утга 
float AmountToBePaid = 0;  // Хүргэлтийн үед бэлэн мөнгө байхгүй 
int DeliveryTypeId = 4;  // EMC 
sbyte TypeOfSeal = 2;  // Бөмбөлөг боолт 
bool SturdyPackaging = үнэн;  // Хатуу савлагаа (эмзэг зүйлсийн хувьд) 
bool Үйл ажиллагаа = үнэн;  // Баримт бичиг шинэчлэгдсэн 
// Захиалга нь 2 зүйлээс бүрдэнэ гэж үзье 
aplix.Godds Бараа = шинэ aplix.Бараа; 
aplix.GoodsItem; 
Item = new aplix.Goods(); 
Item.SKU = "216293"; 
Item.Name = "SDXC 64Gb Class 10 Transcend"; 
Урт = 0.130f; 
Item.Width = 0.100f; 
Item.Height = 0.001f; 
Зүйл.Жин = 0.1f; 
Item.Qty = 1; 
Item.Price = 2080.0f; 
Item.VATRate = "VAT18"; 
Бараа = зүйл; 
Item = new aplix.Goods(); 
Item.SKU = "499687"; 
Item.Name = "Canon EOS 650D Kit Tamron AF 18-270mm Black"; 
Item.Length = 0.1331f; 
Item.Width = 0.0998f; 
Item.Height = 0.0788f; 
Item.Weight = 0.575f; 
Item.Qty = 1; 
Item.Price = 34270.0f; 
Item.VATRate = "VAT18"; 
Бараа = зүйл; 
DateTime DeliveryDate = шинэ DateTime(2013, 09, 05);  //2013 оны 05 сарын 09-ний өдөр хүргэлттэй 
int StartTimeDelivery = 10;  // хүргэх интервал 10-аас 
int EndTimeDelivery = 14;  // 14 хүртэл 
string Comment = "Туршилтын захиалга"; 
//Захиалгыг систем рүү татах 
long OrderId = ws.PushOrder(ID, Дугаар, Огноо, Харилцагч, Зарлагдсан Зардал, Төлбөртэй дүн, Хүргэлтийн төрөл, Битүүмжлэлийн төрөл, Бат бөх сав баглаа боодол, Үйл ажиллагаа, Бараа, Хүргэлтийн Огноо, ЭхлэхЦаг,Хүргэлт дуусах хугацаа, Тайлбар "",); 
Response.Write("Захиалгын ID: " + OrderId.ToString() + "

");


6.4 GetDetailsOfCost арга
Синтакс:        DetailsOfCostList GetDetailsOfCost (ID, TypeId) Параметрүүд:
Оролт гаралт 
Төрөл 
Тодорхойлолт
оролт 
Урт 
CalculateShippingCost аргыг дуудах замаар олж авсан тооцооллын ID (өвөрмөц утга).
оролт 
int 

Параметрийн нэр
ID
TypeId
Тайлбар: Энэ арга нь заасан төлбөрийн ID болон хүргэх сонголтын ID-д зориулж ачааг шошголох, савлах зардлын дэлгэрэнгүй жагсаалтыг буцаана. Буцах утга:Энэ арга нь бүтцийн массивыг буцаана 


Массивын элемент бүр нь зардал, тоо хэмжээ, үнэ, зардлын тайлбарыг агуулдаг.
6.4.1 GetDetailsOfCost аргыг дуудах жишээ

aplix.Delivery ws = шинэ aplix.Delivery(); 
ws.Credentials = шинэ NetworkCredential("туршилт", "туршилт"); 
longID = 168;  // CalculateShippingCost аргаар хүлээн авсан тооцооллын ID 
int TypeId = 3;  // Шуудангийн хүргэлт 

aplix.DetailsOfCost Details = ws.GetDetailsOfCost(ID, TypeId); 
//Үр дүнгийн дүрслэл 
Response.Write("Тооцооны ID: " + ID.ToString() + "

");
Response.Write("Хүргэх аргын id: " + TypeId.ToString() + "

");
Хариулах.Бичих(@"

");
foreach(aplix.DetailsOfCost DetailOfCost дэлгэрэнгүй)
{
Хариулах.Бичих("" + " " + " " + " " + " " + " ");
}
Хариулах.Бичих("

Тодорхойлолт	Үнэ	Тоо ширхэг	зардал
" + DetailOfCost.Description + "	" + DetailOfCost.Price.ToString() + "	" + DetailOfCost.Qty.ToString() + "	" + DetailOfCost.Cost.ToString() + "

");


6.5 PushReestr арга
Синтакс: Long PushOrder (ID, Дугаар, Огноо, Тээвэрлэлтийн огноо, ID) Параметрүүд:
Оролт гаралт 
Төрөл 
Тодорхойлолт
оролт 
Мөр 
Хэрэглэгчийн систем дээрх бүртгэлийн ID (өвөрмөц үнэ цэнэ)
оролт 
Мөр 
Дэлгэрэнгүй мэдээллийг авахыг хүссэн хүргэлтийн сонголтын танигч
оролт 
он сар өдөр цаг 
Бүртгэлийн огноо (тээвэр хүлээн авах гэрчилгээнд хэвлэгдэх болно)
оролт 
он сар өдөр цаг 
Гүйцэтгэгчид эд зүйлсийг шилжүүлэх хүлээгдэж буй огноо
оролт 
Мөр 
Энэ бүртгэлд орсон захиалгын ID-н массив
Параметрийн нэр
ID
тоо
Огноо
Тээвэрлэлтийн огноо
ID
Тайлбар: Арга нь гүйцэтгэгчийн системд бүртгэлийн талаарх мэдээллийг байрлуулдаг.  Систем-хэрэглэгч нь бүртгэлийн дугаар, огноо, бүртгэлийн өвөрмөц танигч, эд зүйлсийг шилжүүлэх хүлээгдэж буй огноог гүйцэтгэгчид дамжуулдаг. Буцах утга:Энэ арга нь гүйцэтгэгчийн систем дэх бүртгэлийн өвөрмөц танигчийг буцаана.
6.5.1 PushReestr аргыг дуудах жишээ

aplix.Delivery ws = шинэ aplix.Delivery(); 
ws.Credentials = шинэ NetworkCredential("туршилт", "туршилт"); 
// Энэ бүртгэлд орсон захиалгын ID-н жагсаалт 
string IDs=("2013-1234567890", "2013-1234567891"); 
// Үйлчлүүлэгчийн систем дэх бүртгэлийн өвөрмөц танигч 
string ID = "2013-r12345"; 
// Үйлчлүүлэгчийн систем дэх бүртгэлийн дугаар 
string Number = "r12345"; 
// Үйлчлүүлэгчийн системд бүртгэл бий болсон огноо 
DateTime Date = шинэ DateTime(2013, 10, 22); 
// Хүргэлтийн захиалгыг шилжүүлэх тооцоолсон огноо 
DateTime DateOfShipment = шинэ DateTime(2013, 10, 23); 
// Тооцооллын дэлгэрэнгүй мэдээллийг авах 
урт ReestID = ws.PushReestr(ID, Дугаар, Огноо, Тээвэрлэлтийн огноо, ID); 
//Үр дүнгийн дүрслэл 
Response.Write("Бүртгэлийн ID: " + ReestID.ToString() + "

");


6.6 GetTrackNumbers арга
Синтакс: огноо GetTrackNumbers(DateOfLastGetting, TrackNumbers) Параметрүүд:
Оролт гаралт 
Төрөл 
Тодорхойлолт
оролт 
он сар өдөр цаг 
Замын дугаарыг хамгийн сүүлд амжилттай хүлээн авсан огноо.  Энэ параметрийг шилжүүлсэн өгөгдлийн хэмжээг багасгах, өмнө нь байршуулсан өгөгдлийг давтахгүйн тулд ашигладаг.
оролт 
Замын дугаар 
Захиалга өгөх замын дугааруудын массив
Параметрийн нэр
DateOfLastGetting
Замын дугаар
Тайлбар: Энэ арга нь DateOfLastGetting хүртэлх хугацаанд захиалгатай холбоотой байсан замын дугааруудын жагсаалтыг буцаана. Одоогийн цаг.  Үр дүнг TrackNumbers гаралтын параметрт байрлуулна.  Хэрэв трекийн дугаар шинэчлэгдсэн бол Activity шинж чанарыг үнэн, үгүй ​​бол худал гэж тохируулна.  Ачаа тээвэрлэлтэд нэг замын дугаар өгөгдсөн бөгөөд хоёр дахь замын дугаарын дараа энэ тохиолдолд анх өгсөн замын дугаар нь хамааралгүй болох тохиолдол байдаг. Буцах утга:Арга нь байршуулсан өгөгдөлд хамааралтай огноо, цагийг буцаана. Өгөгдсөн үнэ цэнэдараагийн удаа GetTrackNumbers аргыг DateOfLastGetting параметрт дуудах үед ашиглах ёстой.
6.6.1 GetTrackNumbers аргыг дуудах жишээ

aplix.Delivery ws = шинэ aplix.Delivery(); 
ws.Credentials = шинэ NetworkCredential("туршилт", "туршилт"); 
// Дууг хамгийн сүүлд амжилттай хүлээн авсан огноо 
DateTime DateOfLastGetting = шинэ DateTime(2013, 08, 01); 
aplix.TrackNumber TrackNumbers; 
// Дууны дугаарын жагсаалтыг авах 
DateTime NewDateOfLastGetting = ws.GetTrackNumbers(DateOfLastGetting, TrackNumbers гарч); 
//Үр дүнгийн дүрслэл 
Response.Write("NewDateOfLastGetting: " + NewDateOfLastGetting.ToString() +"

");
Хариулах.Бичих(@"

");
foreach (TrackNumber дахь aplix.TrackNumber TrackNumber)
{
Хариулах.Бичих("" + " " + " " + " " + " ");
}
Хариулах.Бичих("

Захиалгын ID	Замын дугаар	Үйл ажиллагаа
" + TrackNumber.OrderID.ToString() + "	" + TrackNumber.Number + "	"+TrackNumber. Activity+"

");


API (Application Programming Interface) нь тодорхой төлөөлөлпрограм хоорондын харилцан үйлчлэлийн өгөгдөл.  Тодорхой тохиолдолд сервер хариу програмын үүрэг гүйцэтгэдэг.  API нь өгөгдөл солилцооны хоёр тал дагаж мөрдөх ёстой тодорхойлсон формат юм.
Төрөл бүрийн API-ийн технологи нь харилцан үйлчлэлийн аргуудын багц юм.  API системийг нэг хэлбэрээр эсвэл өөр хэлбэрээр хаа сайгүй танилцуулдаг.  Жишээлбэл, бидний гарт тасалбар худалдаж авах програмтай ухаалаг утас байна.  "Хамгийн дээд" түвшинд бид өгөгдөл оруулах талбар бүхий програмын график хэсгийг хардаг.  Бид тодорхой өдрийн маршрутын дагуу нислэг хийхийг хүсч байгаа бөгөөд тэр үед юу болох вэ:
Гар утасны програм нь серверт хүсэлт үүсгэдэг.  Хүсэлт нь тодорхой хэлбэрээр үүсдэг.  Жишээ нь: Хөдлөх: Москва DME, Ирсэн: АмстердамAMS, Огноо: 2017-01-01, Суудал: 2, Анги: Эдийн засаг.  Энэ мөрөнд хатуу формат орсон - Гарчиг: Утга, таслалаар тусгаарлагдсан бүх утгууд, явах, Ирсэн, Огноо гэсэн шаардлагатай талбарууд, хэрэв өөр өгөгдөл заагаагүй бол тэдгээр нь анхдагч байдлаар байх болно: Суудал: 1, Анги: Эдийн засаг.
Агаарын тээврийн компанийн сервер энэ хүсэлтийг хүлээн авсан бөгөөд хөтөлбөр нь нислэг, үнийг олох шаардлагатай гэдгийг ойлгодог.
Сервер нь SQL дэх мэдээллийн санд ханддаг бөгөөд энэ нь мөн API-ийн хувийн төлөөлөл юм
Өгөгдлийн сан нь файлын системийн API-ээр дамжуулан файлд ханддаг
Файлын систем нь хатуу диск рүү өөрийн API протоколоор ханддаг.
Та үргэлжлүүлэн гүнзгийрүүлж болно, гэхдээ аливаа програмчлалын ажил нь API шатлалыг бий болгож байгаа нь ойлгомжтой.
Өнөөдөр нэг хэлбэрээр эсвэл өөр хэлбэрээр компьютерийн бүх мэдээллийг API-ээр төлөөлдөг.
Бид дээд давхаргад зориулсан API системийг боловсруулдаг бөгөөд дараагийн хэрэглэгч нь үйлчлүүлэгчийн програм юм.
API төрлүүдийн ангилал
Шийдвэрлэж буй даалгавараас хамааран API дамжуулах протоколууд нь стандартчилагдсан болон өөрийн форматтай байж болно.  Хамгийн түгээмэл хэрэглэгддэг стандартчилсан протоколууд нь хөгжүүлэгчдэд бэлэн модулиудыг боловсруулахад ашиглах боломжийг олгодог бөгөөд энэ нь програмыг боловсруулах хугацааг багасгадаг.  Хөдөлгөөний бууралт, командыг таних хурд гэх мэт тодорхой үр дүнд хүрэхийн тулд янз бүрийн тусгай төрлүүдийг ашигладаг бөгөөд зарим тохиолдолд энэ нь цорын ганц боломж юм - өөрийн форматыг хөгжүүлэх, жишээлбэл, эфемерийн бүрэлдэхүүн хэсэг бүхий видеог цацах.
Дамжуулсан мэдээллийн төрлөөс хамааран API нь дараах форматуудад хуваагдана.
Стандарт API протоколууд 
Текст

Хоёртын 
шугаманд
боловсон хүчин

Үйлчлүүлэгч ба серверийн харилцан үйлчлэлийн төрлөөс хамааран дараахь төрлүүд хамгийн түгээмэл байдаг.
Багц 
HTTP/HTTPS
Сокетууд

журам (протокол)
Шугаманд
Нэвтрүүлэг
API системийн хэрэглээ
Бүх онлайн үйлчилгээ, системүүд нийтийн API-тай.  Зарим тохиолдолд та API хандалтыг ашиглахын тулд захиалга эсвэл тодорхой тооны хандалтын төлбөр төлөх шаардлагатай болдог.  Хэрэв таны зорилго бол зарим мэдээллээр хангадаг онлайн үйлчилгээг бий болгох юм бол API-д онцгой анхаарал хандуулаарай.  API функцүүдийн арга барил, сайн баримтжуулалт нь амжилтанд хүрэх түлхүүр юм.  Дараа нь үүсгэх бүх гуравдагч талын хөгжүүлэгчид нэмэлт програмуудЭнэ протоколыг ашиглах шаардлагатай.
API сервер нь бүхэл бүтэн үйлчилгээний цорын ганц өгөгдлийн төлөөлөл бөгөөд үйлчлүүлэгчийн хэсэг нь зөвхөн програмаар дамжуулан ажилладаг нь нэлээд түгээмэл практик юм.  Viber, Instagram, Swarm-ийн тод жишээнүүд - эдгээр програмуудыг зөвхөн Mobile (зөвхөн гар утсан дээр) гэж нэрлэдэг.  Үүнтэй холбогдуулан API серверүүдийн хооронд ачааллыг хуваарилах системийг бий болгох шаардлагатай бөгөөд энэ нь өргөтгөх хүчин чадалтай 24/7 үйлчилгээг бий болгох боломжийг олгоно.  Серверийн хэсгийг үүсгэхийн өмнө та энэ үйл явдлын боломжуудыг нэн даруй үнэлж, хөтөлбөр боловсруулахдаа эдгээр боломжуудыг анхаарч үзэх хэрэгтэй.
Тогтвортой байдалд хүрэхийн тулд Линуксийн орчин болон түүний хөгжүүлэлт системийн үйлчилгээ.  Энэ нь энэхүү үйлдлийн систем нь илүү уян хатан, нөөц ихтэй, нөөцтэй байдагтай холбоотой юм өндөр түвшингэмтлийн бүртгэл болон дибаг хийх.  Вэб серверүүдийг нийтлэгч эсвэл тусгай үйлчилгээ.  Бид API системээр хангахын тулд олон урсгалт үйлчилгээнд хэд хэдэн хөгжүүлэлт хийж байна.
Бид хэрхэн ажилладаг талаар тайлбарласан, үүн дээр хэрхэн мөнгө хийх талаар харцгаая?  Эхний арга нь өөрөө санал болгож байна - API-ээр дамжуулан үйлчилгээ үзүүлэх.  Та үйлчилгээ эсвэл бараагаа шууд зарах боломжтой - рестораны API-тай холбоо барина уу, гэртээ хоол хүргэх захиалга бий болно.  Эсвэл төлбөртэй үйлчилгээ үзүүлэх, жишээлбэл, нягтлан бодох бүртгэлийн тайлан гаргах.
API дээр орлого олох хоёр дахь арга бол хэд хэдэн системийг нэг үйлчилгээнд нэгтгэх явдал юм.  Бид аль хэдийн агаарын тээврийн API-ийн төрлийг хэлэлцсэн боловч хэдэн арван, бүр хэдэн зуун агаарын тээврийн компаниуд байдаг.  Одоо тасалбарын үйлчилгээ түгээмэл болсон - Aviasales, OneTwoTrip, Momondo зэрэг нь үнэндээ юу ч төлөөлдөггүй, зөвхөн агаарын тээврийн компаниудаас өөр өөр API-г авч, эдгээр компаниудаас мэдээлэл цуглуулдаг өөрсдийн үйлчилгээг нийтэлдэг.  Дадлага нь маш түгээмэл бөгөөд өндөр ашигтай байдаг.
API дээр мөнгө олох гурав дахь арга бол "өгөгдлийн холих" арга юм.  Хэрэв бид дахин агаарын тээврийн компанид буцаж ирвэл бид даатгал гэх мэт тэдгээрт үндэслэн холбогдох үйлчилгээг бий болгож чадна.  Бид API мэдээлэлд нислэгээс гадна тодорхой нислэгтэй холбоотой даатгалын мэдээллийг нэмж оруулах үйлчилгээ эсвэл өөр API нэвтрэх цэгийг нийтэлж байна.  Жишээлбэл, агаарын тээврийн компаниуд эсвэл зуучлагчид зочид буудлын талаар мэдээлэл өгөх API-г өргөжүүлээрэй.
API технологийг бий болгох
Бид өмнө нь тайлбарласан бүх төрлийн, протоколын API сервер үүсгэх үйлчилгээгээ санал болгож байна.  Бид янз бүрийн өндөр ачаалалтай системд харилцан үйлчлэлийг бий болгох туршлагатай.  Гаралт дээр бид зөвхөн бэлэн сервер (хар хайрцаг) төдийгүй бас танилцуулж байна Бүрэн тайлбарзураг төслийн баримт бичгийн хэлбэрээр протокол.  Энэхүү протоколын тайлбарыг энэ өгөгдлийг ашиглан дараах хөгжүүлэгчдэд өгч болно нээлттэй хандалтнээлттэй эх сурвалжийн хувьд.
Серверээс гадна бид алдааны дохио өгч, сервер (үүд)-ийн зохицуулалттай ачааллыг давах хянах, аналитик системийг бий болгож чадна.