Независимо от това как се дефинира концепцията за клиент-сървърна архитектура (и в литературата има много такива дефиниции), основата на тази концепция е разпределен компютърен модел. В най-общия случай под клиентИ сървърразбират се два взаимодействащи процеса, единият от които е доставчик на някаква услуга за другия.

Терминът "клиент-сървър" означава архитектура на софтуерен пакет, в която неговите функционални части взаимодействат по схемата "заявка-отговор". Ако разгледаме две взаимодействащи части на този комплекс, тогава едната от тях (клиентът) изпълнява активна функция, т.е. инициира заявки, а другата (сървърът) пасивно отговаря на тях. С развитието на системата ролите могат да се променят, например някой софтуерен блок ще изпълнява едновременно функциите на сървър по отношение на един блок и клиент по отношение на друг.

Сървър - един или повече многопотребителски процесори с едно поле за памет, което в съответствие с нуждите на потребителя им предоставя функции за изчисление, комуникация и достъп до бази данни. сървърможе да се нарече програма, която предоставя някои услуги на други програми. Примери за сървъри са уеб сървърът Apache, сървъри за бази данни - MySQL, ORACLE, мрежови файлови системи и Windows принтери.

клиент - работна станцияза един потребител, осигуряващ режим на регистрация и други функции, необходими на работното му място - изчисления, комуникация, достъп до бази данни и др. Клиент може да се нарече програма, която използва услугата, предоставена от сървърната програма. Примери за клиенти - MSIE (MS Internet Explorer), ICQ клиент.

Често хората просто наричат ​​компютъра, на който работи една от тези програми, като клиент или сървър.

По същество клиентът и сървърът са роли, изпълними програми. Клиентите и сървърите могат физически да пребивават на един и същи компютър. Една и съща програма може да бъде и клиент, и сървър едновременно и т.н... това са само роли.

Ако направим аналогия с обществото - банка или магазин - "сървъри". Те предоставят някои услуги на своите клиенти. Но банката в същото време може да е клиент на друга фирма и т.н.

Обработката клиент-сървър е среда, в която обработката на приложения се разпределя между клиент и сървър. Машините често участват в обработката различни видове, а клиентът и сървърът комуникират помежду си, като използват фиксиран набор от стандартни протоколи за обмен и процедури за достъп до отдалечени платформи.

СУБД с персонални компютри(като Clipper, DBase, FoxPro, Paradox, Clarion имат мрежови версии, които просто споделят файлове с бази данни от същите формати за компютъра, като същевременно прилагат мрежови заключвания за ограничаване на достъпа до таблици и записи. В този случай цялата работа се извършва на компютърът. Сървърът се използва просто като споделен отдалечен диск голям капацитет. Този начин на работа води до риск от загуба на данни поради хардуерни повреди.

В сравнение с такива системи, системите, изградени в архитектурата клиент-сървър, имат следните предимства:

ви позволяват да увеличите размера и сложността на програмите, изпълнявани на работна станция;


осигурява прехвърлянето на най-трудоемките операции към сървър, който е машина с по-голяма изчислителна мощност;


свежда до минимум възможността за загуба на информация, съдържаща се в базата данни, чрез използване на вътрешни механизми за защита на данните, налични на сървъра, като например системи за проследяване на транзакции, връщане назад след повреда и средства за осигуряване на целостта на данните;


намалява няколко пъти количеството информация, предавана по мрежата.


В архитектура клиент-сървър сървърът на базата данни не само осигурява достъп до споделени данни, но също така обработва цялата обработка на тези данни. Клиентът изпраща заявки към сървъра за четене или промяна на данни, които са формулирани в SQL. Самият сървър прави всички необходими промени или селекции, като същевременно наблюдава целостта и последователността на данните и изпраща резултатите под формата на набор от записи или код за връщане към компютъра на клиента.


Тя ви позволява оптимално да разпределите изчислителното натоварване между клиента и сървъра, което също засяга много характеристики на системата: цена, производителност, поддръжка.


1.2. История…


Архитектурата и терминът "клиент-сървър" са използвани за първи път в началото на 80-те години. Първите приложения с архитектура клиент-сървър бяха бази данни.


Преди това нямаше ясно разделение - програмата обикновено правеше всичко сама - включително работа с данни в файлова система, представяне на данни на потребителя и т.н. С течение на времето обемът и критичността на данните за бизнеса нараснаха и това с времето започна да поражда проблеми (производителност, сигурност и други).


Тогава те разбраха, че би било удобно да инсталират базата данни на мощен отделен компютър(сървър) и позволи тази база данни да се използва от много малки компютърни потребители (клиенти) през мрежата, което беше направено.


По същество „експлозията“ в популярността на технологията клиент-сървър беше причинена от изобретението на IBM за прост език за заявки релационни бази данни SQL данни. Днес SQL е универсалният стандарт за работа с бази данни. Напоследък тази „експлозия“ продължава с изобретяването на Интернет, в който буквално всяко взаимодействие се осъществява според архитектура „клиент-сървър“.


1.3. протоколи


Сървърът и клиентът в мрежата „говорят“ помежду си на „език“ (в широкия смисъл на думата), който е разбираем и за двете страни. Този „език“ се нарича протокол.


При банката протокол може да се нарече формулярите, които клиентът попълва.


В нашия случай примери за протоколи:


FTP ( Прехвърляне на файлпротокол)


HTTP (протокол за прехвърляне на хипертекст)


SMTP (прост протокол за прехвърляне на поща)


IP (интернет протокол)


MySQL клиент/сървър протокол


Имайте предвид, че протоколите могат да бъдат различни нива. Класификационните системи на нивата може да са различни, но една от най-известните линии е OSI (взаимосвързаност на отворени системи), която има 7 нива.


Например HTTP е протокол на приложен (седми - най-висок) слой, а IP е протокол на мрежов (трети) слой.


1.4. Разпределение на функциите в архитектурата клиент-сървър


IN класическа архитектураКлиент-сървърът трябва да разпредели трите основни части на приложението в два физически модула. Обикновено софтуерът за съхранение на данни се намира на сървър (например сървър на база данни), потребителският интерфейс е от страната на клиента, но обработката на данни трябва да бъде разпределена между клиентската и сървърната част. Това е основният недостатък на двустепенната архитектура, от която няколко неприятни черти, което значително усложнява развитието на системите клиент-сървър.


Процесът на разработка на такива системи е доста сложен и една от най-важните задачи е решението как да се разпредели функционалността на приложението между клиентската и сървърната част. Опитвайки се да разрешат този проблем, разработчиците получават двустепенна, тристепенна и многослойна архитектура. Всичко зависи от това колко междинни връзки са включени между клиента и сървъра.


Основният проблем, който решава клиентско приложение, осигурява интерфейс с потребителя, т.е. въвеждане на данни и представяне на резултатите в удобна за потребителя форма и управление на сценарии за приложение.


Основните функции на сървърната СУБД са осигуряване на надеждност, последователност и сигурност на данните, управление на клиентски заявки и бърза обработка на SQL заявки.


Цялата логика на приложението - задачи на приложението, бизнес правила - в двустепенна архитектура се разпределя от разработчика между два процеса: клиент и сървър (фиг. 1).


Първоначално повечето от функциите на приложението бяха решени от клиента, сървърът беше включен само в обработката на SQL заявки. Тази архитектура се нарича "дебел клиент - тънък сървър".


Появата на възможността за създаване на съхранени процедури на сървъра, т.е. компилирани програми с вътрешна операционна логика, доведе до тенденция за прехвърляне на все по-голяма част от функциите към сървъра. Сървърът ставаше все по-„дебел“, а клиентът ставаше „по-тънък“.


Това решение има очевидни предимства, например, по-лесно се поддържа, защото всички промени трябва да се правят само на едно място - на сървъра.


Обсъдените по-горе модели имат следните недостатъци.


1. „Дебел“ клиент:


– сложност на администрирането;


– обновяването на софтуера става по-сложно, тъй като трябва да се смени едновременно в цялата система;


– разпределението на правомощията става по-сложно, тъй като достъпът е ограничен не от действия, а от таблици;


– мрежата е претоварена поради предаване на необработени данни през нея;


– слаба защита на данните, тъй като е трудно да се разпределят правилно правомощията.


2. „Дебел“ сървър:


– изпълнението става по-сложно, тъй като езици като PL/SQL не са подходящи за разработване на такъв софтуер и няма добри средстваотстраняване на грешки;


– производителността на програми, написани на езици като PL/SQL, е значително по-ниска от тези, създадени на други езици, което има важноза сложни системи;


– програмите, написани на СУБД езици обикновено не работят надеждно; грешка в тях може да доведе до отказ на целия сървър на база данни;


– получените програми са напълно непреносими към други системи и платформи.


За решаването на тези проблеми се използват многостепенни (три или повече нива) архитектури клиент-сървър. слоеста архитектураклиент-сървър ви позволява значително да опростите разпределените изчисления, правейки ги не само по-надеждни, но и по-достъпни.


Въпреки това, езикът, на който са написани съхранените процедури, не е достатъчно мощен или гъвкав, за да реализира лесно сложна логика на приложението.


Тогава имаше тенденция да се поверява изпълнението на приложни задачи и бизнес правила на отделен приложен компонент (или няколко компонента), който може да работи или на специално предназначен компютър - сървър на приложения, или на същия компютър, където работи сървърът на базата данни . Така се появиха тристепенните и многослойните клиент-сървър архитектури.





Ориз. 1. Разпределение на функциите между клиент и сървър


Имаше специална софтуерМидълуер (софтуер), който трябва да позволява на множеството компоненти на такова многокомпонентно приложение да функционират заедно. Такива приложения са гъвкави, мащабируеми, но трудни за разработване.



БИБЛИОГРАФИЯ

1. Информатика / Ред. Н.В. Макарова – М.: Финанси и статистика, 1998.
   

   Евдокимов В.В. и др.Икономическа информатика. Санкт Петербург: Питър, 2004.
   

   Казаков С.И. Основи мрежови технологии– М.: Радио и комуникации, 2004.
   

   Когаловски М. Р., Технология за бази данни на персонални компютри, - М .: Финанси и статистика, 2003 г.
   

   Попов В.В. Основи на компютърните технологии. – М .: Финанси и статистика, 2001.
   

   Фигурнов В.Е. IBM PC за потребителя. М., 2000.
   

ОПЕРАЦИОННА СИСТЕМА MS-DOS. ОСНОВНИ ПОНЯТИЯ И КОМАНДИ ОСНОВНИ ПОНЯТИЯ: БАЗА ДАННИ, СУБД, СУБЕКТ, АТРИБУТ, ВРЪЗКА (ЕДНО КЪМ ЕДНО, ЕДНО КЪМ МНОГО, МНОГО КЪМ МНОГО), ВРЪЗКА, ПЪРВИЧЕН КЛЮЧ

DB, работещи с помощта на технологията FILE SERVER;

Бази данни, работещи по технологията КЛИЕНТ-СЪРВЪР.

Файлов сървър

- Достъп до базата данни (запитване)
- Прехвърляне на данни, докато блокира достъпа на други потребители
- Обработка на данни на компютъра на потребителя

За по-голяма яснота, нека разгледаме конкретни примери. Да приемем, че трябва да прегледате изпратените платежни нареждания за периода от 19 май до 25 май в размер на 5000 рубли. Потребителят ще трябва да стартира клиентско приложение на своя компютър, което работи в базата данни с платежни нареждания, и да въведе необходимите критерии за избор. След което ще бъде изтеглен на вашия компютър от сървъра на базата данни и зареден в RAMфайл, съдържащ всички документи от този тип за целия период за всякакви суми. Клиентско приложение, работещо на компютъра на потребителя, което работи с базата данни, ще обработи тази информация (сортира я) и след това ще даде отговор (на екрана ще се появи списък с платежни нареждания, които отговарят на вашите критерии). След това ще изберете желаното платежно нареждане и ще опитате да редактирате (промените) едно поле в него - например датата. По време на редактиране източникът на данни е блокиран, т.е. целият файл, съдържащ този документ. Това означава, че файлът или изобщо няма да бъде достъпен за други потребители, или ще бъде достъпен само в режим на преглед. Освен това този вид улавяне дори не се случва на ниво запис, тоест един документ, а целият файл е заключен - тоест цялата таблица, съдържаща подобни документи. Едва след като това поле бъде напълно обработено и се излезе от режима на редактиране, този файл с платежно нареждане ще бъде отключен от заснемане от потребителя. Ако данните се съхраняват в по-големи обекти, например един файл съдържа платежни нареждания както за получаване на средства, така и за изпращане на средства, тогава още повече от информацията няма да бъде налична. Ще работите с едно поле "дата" в един документ - останалите служители на предприятието ще изчакат, докато приключите.

Недостатъците на системата FILE SERVER са очевидни:

Много огромен натискв мрежата, повишени изисквания за честотна лента. На практика това прави почти невъзможно едновременната работа голямо числопотребители с големи количества данни.

Обработката на данните се извършва на компютъра на потребителите. Това води до повишени хардуерни изисквания за всеки потребител. Колкото повече потребители, толкова повече парище трябва да бъдат изразходвани за оборудване на техните компютри.

Заключването на данни при редактиране от един потребител прави невъзможно други потребители да работят с тези данни.

Безопасност. За да можете да работите с такава система, ще трябва да дадете на всеки потребител пълен достъп до целия файл, в който той може да се интересува само от едно поле.

Клиентски сървър

Обработка на заявка от един потребител:
- Достъп до базата данни (SQL заявка)
- Предаване на отговора - резултат от обработката




Ако е необходимо да се обработи информация, съхранявана в базата данни, клиентско приложение, работещо на компютъра на потребителя, което работи с базата данни, генерира заявка на езика SQL (име от началните букви - Structured Query Language). Сървърът на базата данни приема заявката и я обработва независимо. По мрежата не се предава масив от данни (файл). След обработка на заявката, само резултатът се прехвърля на компютъра на потребителя - тоест в предишния пример списък с платежни нареждания, които отговарят на необходимите критерии. Самият файл, в който се съхраняват данните, послужили като източник за обработка, остава деблокиран за достъп от самия сървър по искане на други потребители.

В сериозните клиент-сървър СУБД има допълнителни механизми, намаляване на натоварването на мрежата, намаляване на изискванията за потребителски компютри. Като пример ще дадем съхранени процедури – тоест цели програми за обработка на данни, съхранявани в базата данни. В този случай дори SQL изразите не се прехвърлят от потребителя към сървъра - прехвърля се извикване на функция с параметри на извикване. По този начин, работно мястопотребителското изживяване е допълнително опростено, логиката на програмата се прехвърля на сървъра. Потребителското пространство става просто средство за показване на информация. Всичко това означава допълнително намаляване на натоварването на мрежата и потребителските работни станции.

Така че всичко горните недостатъциСхемите FILE-SERVER са елиминирани в архитектурата CLIENT-SERVER:

Масивите от данни не се прехвърлят по мрежата от сървъра на базата данни към компютъра на потребителя. Изискванията за честотна лента на мрежата са намалени. Това дава възможност на голям брой потребители да работят едновременно с големи количества данни.

Обработката на данни се извършва на сървъра на базата данни, а не на компютъра на потребителите. Това позволява използването на по-прости и следователно по-евтини компютри в клиентските сайтове.

Данните не се блокират (прихващат) от един потребител.

На потребителя се предоставя достъп не до целия файл, а само до данните от него, с които потребителят има право да работи.

След като разгледахме разликата между ФАЙЛОВ СЪРВЪР и КЛИЕНТСКИ СЪРВЪР, можем да завършим нашето разглеждане на концепцията за „съхранение на информация“. Важно е да се подчертае, че работата на корпоративната система до голяма степен зависи от вида на използваната СУБД. Съвсем очевидно е, че за големите предприятия, с голяма сумапотребители, с огромен бройзаписи в базата данни, схемата файл-сървър е напълно неприемлива. От друга страна, има разлики в базите данни в други параметри и възможности:

видове данни, които могат да се съхраняват в базата данни (числа, дати, текст, снимки, видео, звук и др.);

относно технологиите, организирани от самата база данни за достъп до данни в базата данни и нивото на защита на информацията от неоторизиран достъп;

относно предоставените инструменти и методи за разработка, които могат да се използват за проектиране на всяка информационна система, базирана на тази база данни;

относно предоставените инструменти и методи за анализ на информация (данни), които могат да бъдат приложени в информационна система, базирана на тази база данни;

по отношение на надеждност и стабилност, това е (приблизително) броят на записите (попълнените полета) в базата данни, което гарантира надеждна и непрекъсната възможност за достъп, промяна и анализ на информация в базата данни;

по скорост - времето за достъп и обработка на информацията;

ако е възможно, организирайте работа на компютри различни производители, тоест съвместимост с други платформи и операционни системи;

от нивото на поддръжка (услуга), предоставена от разработчика на базата данни или неговия оторизиран дилър;

върху наличието на добри инструменти за създаване на приложения, които използват тази база данниданни и др.

Защо днес не е изгодно да се инвестира в решение за файлов сървър? Днес бъдещият път на развитие на бази данни вече е очевиден. Появяват се многостепенни клиент-сървър системи с много тънки клиенти, премахващи всякакви ограничения от клиентските станции, както по отношение на производителността, така и по отношение на платформата и операционната система. Ако за решение клиент-сървър по-нататъчно развитиеизглежда напълно ясно и преходът от клиент-сървър към многостепенен клиент-сървър не е проблематичен, тогава за файлов сървър простият преход към клиент-сървър представлява огромен проблем и огромни разходи за труд, ако това изведнъж се окаже изобщо да е възможно.

Владимир, уеб разработчик в Noveo, казва:

Повечето разработчици на уебсайтове, уеб услуги и мобилни приложения рано или късно трябва да се справят с архитектурата клиент-сървър, а именно да разработят уеб API или да се интегрират с него. За да не се измисля нещо ново всеки път, важно е да се разработи сравнително универсален подход към дизайна на уеб API, базиран на опита от разработването на подобни системи. Предлагаме на вашето внимание сборна поредица от статии, посветени на този проблем.

Приближение едно: Герои

В един момент, в процеса на създаване на друга уеб услуга, реших да събера всичките си знания и мисли по темата за проектиране на уеб API, който да обслужва нуждите на клиентските приложения, и да го представя под формата на статия или поредица от статии. Разбира се, моят опит не е абсолютен и градивната критика и допълнения са повече от добре дошли.

Четивото се оказа по-скоро философско, отколкото техническо, но за любителите на техническата част ще има над какво да се замислят. Съмнявам се, че в тази статия ще кажа нещо принципно ново, нещо, което никога не сте чували, чели или мислили за себе си. Просто се опитвам да вместя всичко единна система, преди всичко в собствената си глава, а това вече струва много. Въпреки това ще се радвам, ако моите мисли ще ви бъдат полезни във вашата практика. И така, да вървим.

Клиент и сървър

сървърв този случай ние разглеждаме абстрактна машина в мрежата, която е в състояние да получи HTTP заявка, да я обработи и да върне правилния отговор. В контекста на тази статия неговата физическа същност и вътрешна архитектура са напълно маловажни, било то студентски лаптоп или огромен клъстер от индустриални сървъри, разпръснати по целия свят. По същия начин за нас няма значение какво има под капака, кой поздравява заявката на вратата, Apache или Nginx, какъв неизвестен звяр, PHP, Python или Ruby я обработва и генерира отговор, какво съхранение на данни се използва : Postgresql, MySQL или MongoDB. Основното е, че сървърът отговаря на основното правило - да чува, разбира и прощава.

Клиентможе да бъде и всичко, което може да генерира и изпрати HTTP заявка. До определен момент в тази статия също няма да се интересуваме особено от целите, които клиентът си поставя при изпращането на тази заявка, нито какво ще направи с отговора. Клиентът може да бъде JavaScript скрипт, работещ в браузъра, мобилно приложение, зъл (или не толкова зъл) демон, работещ на сървъра, или прекалено мъдър хладилник (вече има такива неща).

В по-голямата си част ще говорим за начина на комуникация между горните двама, така че да се разбират и никой от тях да няма въпроси.

ПОЧИВКА Философия

REST (Representational state transfer) първоначално е замислен като прост и недвусмислен интерфейс за управление на данни, който включва само няколко основни операции с директно мрежово съхранение (сървър): извличане на данни (GET), запазване (POST), модификация (PUT/PATCH ) и изтриване (DELETE). Разбира се, този списък винаги е бил придружен от такива опции като обработка на грешки в заявката (правилно ли е съставена заявката), ограничаване на достъпа до данни (внезапно не трябва да знаете това) и валидиране на входящи данни (внезапно сте написали глупости), в общо, от всички евентуални проверки, който сървърът изпълнява преди да изпълни желанието клиент.

Освен това REST има редица архитектурни принципи, чийто списък може да бъде намерен във всяка друга статия за REST. Нека ги прегледаме накратко, за да са ви под ръка и да не се налага да ходите никъде:

Независимост на сървъра от клиента- сървърите и клиентите могат незабавно да бъдат заменени от други, независимо един от друг, тъй като интерфейсът между тях не се променя. Сървърът не съхранява клиентски състояния.
Уникалност на адресите на ресурсите- всяка единица данни (с всякаква степен на вложеност) има свой собствен уникален URL адрес, който всъщност е изцяло уникален идентификатор на ресурс.

Пример:ВЗЕМЕТЕ /api/v1/users/25/име

Независимост на формата за съхранение на данни от формата на предаване- сървърът може да поддържа няколко различни форматиза прехвърляне на същите данни (JSON, XML и др.), но съхранява данните във вътрешния си формат, независимо от поддържаните.

Наличие на всички необходими метаданни в отговора- в допълнение към самите данни, сървърът трябва да върне подробности за обработката на заявката, например съобщения за грешки, различни свойства на ресурсите, необходими за по-нататъшна работас него, например, общия брой записи в колекцията за правилно показване на навигацията по страниците. По-късно ще разгледаме различните видове ресурси.

Какво ни липсва?

Класическият REST включва работата на клиента със сървъра като с плоско хранилище на данни, като нищо не се казва за свързаността и взаимозависимостта на данните помежду им. Всичко това по подразбиране пада изцяло върху плещите на клиентското приложение. Но съвременните предметни области, за които се разработват системи за управление на данни, било то социални услуги или системи за онлайн маркетинг, предполагат сложна връзка между обектите, съхранявани в базата данни. Поддържайки тези връзки, т.е. целостта на данните е отговорност на сървъра, докато клиентът е само интерфейс за достъп до тези данни. И така, какво ни липсва в 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. Можете да използвате всеки от тях, в зависимост от вашите нужди и изисквания.

Автономност на компонентите

Уеб API на сложни системи, които поддържат множество потребителски роли, често изисква разделяне на части, всяка от които обслужва своя собствен набор от задачи. Всъщност всяка част може да бъде самостоятелно приложение, работа по различни физически машинии платформи. В контекста на описанието на API, за нас изобщо не е важно как сървърът обработва заявката и какви сили и технологии са включени в това. За клиента API е капсулирана система. Различните части на системата обаче могат да имат напълно различна функционалност, например административната и потребителската част. И методологията за работа с привидно едни и същи ресурси може да се различава значително. Следователно такива части трябва да бъдат разделени на ниво домейн admin.v1.example-api.com или префикс на пътя example-api.com/v1/admin/. Това изискване не е задължително и много зависи от сложността на системата и нейното предназначение.

Формат за обмен на данни

Най-удобният и функционален, по мое мнение, формат за обмен на данни е JSON, но никой не забранява използването на XML, YAML или друг формат, който ви позволява да съхранявате сериализирани обекти, без да губите типа на данните. При желание можете да го направите в API поддръжкамножество входно/изходни формати. Достатъчно е да използвате заглавката на HTTP заявката, за да посочите желания формат на отговора за приемане и Content-Type, за да посочите формата на данните, предадени в заявката. На другите популярен начине да добавите разширение към URL адреса на ресурса, например GET /users.xml, но този метод изглежда по-малко гъвкав и красив, дори само защото прави URL адреса по-тежък и е верен повече за GET заявки, отколкото за всички възможни операции.

Локализация и многоезичие

На практика многоезичието на API най-често се свежда до превод на съобщения за услуги и грешки на необходимия език за директно показване на крайния потребител. Многоезичното съдържание също има своето място, но съхраняването и издаването на съдържание на различни езици, според мен трябва да се разграничат по-ясно, например, ако имате една и съща статия на различни езици, то всъщност това са две различни единици, групирани въз основа на единството на съдържанието. Могат да се използват различни методи за идентифициране на очаквания език. Най-простият е стандартният HTTP хедър Accept-Language. Виждал съм други начини, като добавяне на GET параметър language="en" , използване на префикса на пътя example-api.com/en/ или дори на ниво име на домейн en.example-api.com . Струва ми се, че изборът как да се посочи локалът зависи от конкретното приложение и задачите, които стоят пред него.

Вътрешно маршрутизиране

Така че стигнахме до основния възел на нашия API (или един от неговите компоненти). Всички следващи маршрути ще минават директно във вашия сървърно приложение, според набора от ресурси, които поддържа.

Събирателни пътища

За да посочим пътя към колекцията, ние просто използваме името на съответния обект, например, ако това е списък с потребители, тогава пътят ще бъде /потребители. За колекцията като такава са приложими два метода: GET (получаване на ограничен списък от обекти) и POST (създаване на нов елемент). В заявките за списъци можем да използваме много допълнителни GET параметри, за които сме свикнали извеждане на страницата, сортиране, филтриране, търсене и т.н., но те трябва да са незадължителни, т.е. тези параметри не трябва да се предават като част от пътя!

Колекция елементи

За достъп до определен елемент от колекцията, ние го използваме в маршрута уникален идентификатор/потребители/25. Това е уникалният път към него. За работа с обект са приложими методите GET (получаване на обект), PUT/PATCH (промяна) и DELETE (изтриване).

Уникални предмети

Много услуги имат обекти, които са уникални за текущия потребител, като например профил /profile на текущия потребител или лични настройки /settings. Разбира се, от една страна, това са елементи на една от колекциите, но те са отправната точка за използването на нашия Web API от клиентското приложение, а също така позволяват много по-широк набор от операции с данни. В същото време колекцията се съхранява потребителски настройкиможе изобщо да не е достъпно поради съображения за сигурност и поверителност на данните.

Свойства на обекти и колекции

За да стигнете директно до някое от свойствата на даден обект, достатъчно е да добавите името на свойството към пътя към обекта, например вземете потребителското име /users/25/name . Методите GET (получаване на стойност) и PUT/PATCH (промяна на стойност) са приложими към свойство. Методът DELETE не е приложим, защото свойство е структурна част от обект, като формализирана единица от данни.

В предишната част говорихме за факта, че колекциите, подобно на обектите, могат да имат свои собствени свойства. Според моя опит единственото свойство, което намирам за полезно, е свойството count, но вашето приложение може да е по-сложно и специфично. Пътищата към свойствата на колекцията се изграждат по същия принцип, както към свойствата на техните елементи: /users/count. За свойствата на колекцията е приложим само методът GET (получаване на свойство), тъй като колекцията е просто интерфейс за достъп до списък.

Колекции от свързани обекти

Един тип свойство на обекта може да бъде свързани обекти или колекции от свързани обекти. Такива обекти, като правило, не са собствена собственост на обекта, а само препратки към връзките му с други обекти. Например списък с роли, които са присвоени на потребителя /users/25/roles. Ще говорим подробно за работата с вложени обекти и колекции в една от следващите части и нататък на този етапЗа нас е достатъчно, че имаме възможност за директен достъп до тях, както всяко друго свойство на обект.

Функции на предмети и колекции

За да изградим пътя до интерфейса за извикване на функция на колекция или обект, ние използваме същия подход като за достъп до свойство. Например за обекта /users/25/sendPasswordReminder или колекцията /users/disableUnconfirmed. За извиквания на функции винаги използваме метода POST. Защо? Нека ви напомня, че в класическия REST няма специален глагол за извикване на функции и затова ще трябва да използваме един от съществуващите. Според мен методът POST е най-подходящ за това, защото... той ви позволява да предавате необходимите аргументи на сървъра, не е идемпотентен (връща същия резултат при многократен достъп) и е най-абстрактният в семантиката.

Надявам се горе-долу всичко да пасне в системата :) В следващата част ще говорим по-подробно за заявките и отговорите, техните формати и кодове за състояние.

Трето приближение: Запитвания и отговори

В предишни приближения говорих за това как дойде идеята да събера и обобщя съществуващия опит в разработването на уеб API. В първата част се опитах да опиша с какви типове ресурси и операции върху тях имаме работа, когато проектираме уеб API. Втората част засегна въпросите за изграждането на уникални URL адреси за достъп до тези ресурси. И в това приближение ще се опитам да опиша възможните варианти за заявки и отговори.

Универсален отговор

Вече казахме, че конкретният формат на комуникация между сървъра и клиента може да бъде всеки по преценка на разработчика. За мен форматът JSON изглежда най-удобен и визуален, въпреки че едно реално приложение може да поддържа няколко формата. Сега нека се съсредоточим върху структурата и необходимите атрибути на обекта за отговор. Да, ние ще опаковаме всички данни, върнати от сървъра, в специален контейнер - общ обект на отговор, който ще съдържа всички необходими сервизна информацияза по-нататъшната му обработка. И така, каква е тази информация:

Успех - маркер за успех на заявката

За да разберете незабавно при получаване на отговор от сървъра дали заявката е била успешна и да я предадете на съответния манипулатор, достатъчно е да използвате токена за успех „успех“. Най-простият отговор на сървъра, който не съдържа данни, би изглеждал така:

POST /api/v1/articles/22/publish ("успех": вярно)

Грешка - информация за грешка

Ако заявката е неуспешна - ще говорим за причините и видовете отрицателни отговори на сървъра малко по-късно - атрибутът „грешка“ се добавя към отговора, съдържащ HTTP кода на състоянието и текста на съобщението за грешка. Моля, не бъркайте със съобщения за грешки при валидиранеданни за конкретни полета. Най-правилно според мен е да се върне кодът на състоянието в заглавката на отговора, но съм виждал и друг подход - винаги да се връща статус 200 (успех) в заглавката и да се изпращат подробности и данни за възможни грешки в тялото на отговор.

GET /api/v1/user ("успех": невярно, "грешка": ("код": 401, "съобщение": "Неуспешна авторизация"))

Данни - данни, върнати от сървъра

Повечето сървърни отговори са проектирани да връщат данни. В зависимост от вида на заявката и нейния успех, очакваният набор от данни ще варира, но атрибутът „данни“ ще присъства в по-голямата част от отговорите.

Пример за върнати данни при успех. В този случай отговорът съдържа искания потребителски обект.

GET /api/v1/user ("success": true, "data": ( "id": 125, "email": "[email protected]", "name": "John", "familia" : "Смит", ) )

Пример за върнатите данни в случай на грешка. В този случай той съдържа имена на полета и съобщения за грешка при валидиране.

PUT /api/v1/user ( "успех": невярно, "грешка": ( "код": 422, "съобщение": "Неуспешно потвърждение") "данни": ( "имейл": "Имейлът не може да бъде празен. ", ))

Страниране - информация, необходима за организиране на навигацията на страницата

В допълнение към самите данни, в отговорите се връщат набор от елементи за събиране, трябва да присъства информация за навигация на страници (страниране) въз основа на резултатите от заявката.

Минималният набор от стойности за страниране се състои от:

• общ брой записи;
• брой страници;
• текущи номера на страници;
• брой записи на страница;
• максималният брой записи на страница, поддържани от страната на сървъра.

някои уеб разработчици API също така включват в пагинацията набор от готови връзки към съседни страници, както и първа, последна и текуща.

GET /api/v1/articles Response: ( "success": true, "data": [ ( "id" : 1, "title" : "Интересно нещо", ), ( "id" : 2, "title" : „Скучен текст“, ) ], „pagination“: ( „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 методи, ПОСТАВЯНЕ и ИЗТРИВАНЕ. Ако данните не са валидирани, сървърът връща отчет в секцията „данни“ за това кои параметри са невалидни и защо.

HTTP протоколът поддържа много по-голям бройразлични кодове за състояние за всички случаи, но на практика те се използват рядко и в контекста на уеб API нямат практическа полза. Доколкото си спомням, никога не ми се е налагало да надхвърлям горния списък с изключения.

Заявки

Извличане на елементи от колекцията

Едно от най-често срещаните искания е искането за получаване на елементи от колекцията. Клиентското приложение показва емисии с информация, списъци с продукти, различни информационни и статистически таблици и много други чрез достъп до ресурси за събиране. За да направим тази заявка, ние осъществяваме достъп до колекцията, използвайки метода GET и предавайки допълнителни параметри в низа на заявката. Както вече посочихме по-горе, като отговор очакваме да получим масив от хомогенни елементи на колекцията и информацията, необходима за страниране - зареждане на продължението на списъка или негова конкретна страница. Съдържанието на селекцията може да бъде специално ограничено и сортирано с помощта на трансфера допълнителни параметри. Те ще бъдат обсъдени допълнително.

Навигация в страницата

страница- параметърът показва коя страница трябва да се покаже. Ако този параметър не бъде подаден, тогава се показва първата страница. От първия успешен отговор от сървъра ще стане ясно колко страници има колекцията с текущите параметри на филтриране. Ако стойността надвишава максималния брой страници, най-добре е да върнете грешка 404 Страницата не е намерена.

ВЗЕМЕТЕ /api/v1/news?page=1

на страница- показва желания брой елементи на страницата. Обикновено API има собствена стойностпо подразбиране, което връща perPage като поле в секцията за страниране, но в някои случаи ви позволява да увеличите тази стойност до разумни граници, като предоставите максимална стойност maxPerPage:

ВЗЕМЕТЕ /api/v1/news?perPage=100

Сортиране на резултатите

Често искате да сортирате резултатите от селекция чрез възходящи или низходящи стойности на определени полета, които поддържат сравнително (за числови полета) или азбучно (за низови полета) сортиране. Например, трябва да организираме списък с потребители по име или продукти по цена. Освен това можем да зададем посоката на сортиране от А до Я или в обратната посока, като тя е различна за различните полета.

сортиране по- има няколко подхода за предаване на сложни сортирани данни в GET параметри. Тук е необходимо ясно да посочите реда и посоката на сортиране.

Някои API предлагат да направите това като низ:

GET /api/v1/products?sortBy=name.desc,price.asc

Други опции предлагат използването на масив:

ВЗЕМЕТЕ /api/v1/продукти? sortBy=име& sortBy=desc& sortBy=цена& sortBy=възходящ

Като цяло и двете опции са еквивалентни, тъй като предават едни и същи инструкции. Според мен вариантът с масив е по-универсален, но, както се казва, зависи от вкуса и цвета...

Лесно филтриране по стойност

За да филтрирате селекция по стойността на дадено поле, в повечето случаи е достатъчно да подадете името на полето и необходимата стойност като филтърен параметър. Например искаме да филтрираме статиите по ID на автора:

GET /api/v1/articles?authorId=25

Разширени опции за филтриране

Много интерфейси изискват по-сложни системи за филтриране и търсене. Ще изброя основните и най-често срещаните опции за филтриране.

Филтриране по горни и долни граници с помощта на оператори за сравнение от (по-голямо или равно на), по-високо (по-голямо от), до (по-малко или равно на), по-ниско (по-малко от). Прилага се за полета, чиито стойности могат да бъдат класирани.

ВЗЕМЕТЕ /api/v1/products?price=500&price=1000

Филтрирайте по няколко възможни стойности от списъка. Прилага се за полета, чийто набор от възможни стойности е ограничен, например филтър с няколко статуса:

ВЗЕМЕТЕ /api/v1/products?status=1&status=2

Филтриране по частично съвпадение на низ. Прилага се за полета, съдържащи текстови данни или данни, които могат да бъдат приравнени към текст, като числови SKU на продукти, телефонни номера и др.

GET /api/v1/users?name=Джон GET /api/v1/products?code=123

Именувани филтри

В някои случаи, когато определени набори от параметри на филтъра се използват често и се подразбират от системата като нещо холистично, особено ако засягат вътрешната, често сложна механика на вземане на проби, препоръчително е да ги групирате в така наречените именувани филтри. Достатъчно е да подадете името на филтъра в заявката и системата автоматично ще изгради селекцията.

GET /api/v1/products?filters=recommended

Наименуваните филтри също могат да имат свои собствени параметри.

ВЗЕМЕТЕ /api/v1/products?filters=kidds

В този подраздел се опитах да говоря за най-популярните опции и методи за получаване на необходимата проба. Най-вероятно във вашата практика ще има много повече примери и нюанси по тази тема. Ако имате какво да добавите към моя материал, ще се радвам. Междувременно публикацията вече е нараснала до значителен мащаб, така че ще анализираме други видове заявки в следващото приближение.

Терминът "клиент-сървър" може да опише Хардуери в този случай означава мрежови сървър и клиентски компютри или начин за организиране на софтуер и услуги в мрежа.

Модел клиент-сървър (клиент/сървър) – изчислителен модел, при който обработващото натоварване приложни програмиразпределен между клиентски компютър и сървърен компютър, който споделя информация чрез мрежа. Този модел съчетава предимствата на централизираното изчисление и клиентския модел. Обикновено клиентът е софтуер за краен потребител, работещ на WS и способен да комуникира със сървър (обикновено сървър на база данни). Производителността при използване на модела клиент-сървър е по-висока от обикновено, тъй като клиентът и сървърът споделят натоварването при обработка на данни. Моделът клиент-сървър работи най-добре при достъп до големи количества данни.

Архитектурата клиент-сървър е начин за организиране на взаимодействието на програми или компоненти на многокомпонентна програма, което предполага наличието на програма или програмен компонент, наречен сървър, и един или повече други компоненти, наречени клиенти.

Клиентът е компонент на локална мрежа, който иска услуги от някакъв сървър, а сървърът е компонент на локална мрежа, който предоставя услуги на някои клиенти. Сървърът на локалната мрежа предоставя ресурси (услуги) на работни станции и/или други сървъри. В система клиент-сървър клиентът изпраща заявка до сървъра и цялата обработка на информация се извършва на сървъра.

Ядрото на архитектурата клиент/сървър е сървърът на база данни (система, която получава заявки от клиентски програми през компютърна мрежа и отговаря с исканите данни (набор от отговори); всеки сървър на база данни се състои от компютър, операционна системаи DBMS сървърен софтуер), което е приложение, което извършва набор от действия за управление на данни: изпълнение на заявки, съхраняване и архивиране на данни, проследяване на референтната цялост, проверка на потребителски права и привилегии и поддържане на регистър на транзакциите. Обикновено клиентите в компютърна мрежа изпращат заявки към сървъра под формата на изречения на SQL език. Сървърът ги интерпретира и изпраща съответните данни обратно на клиента.

Клиентът има възможност да инициира изпълнението на сървърни процедури асинхронно за сървъра и да получава резултатите от тяхното изпълнение. Обикновено архитектурата клиент-сървър позволява на множество клиенти да взаимодействат със сървър паралелно и независимо един от друг.

В най-простата си форма архитектурата клиент-сървър се състои от три основни компонента:

Сървър на база данни, който управлява съхранение на данни, достъп и сигурност, архивиране, следи целостта на данните според бизнес правилата и, най-важното, изпълнява заявки на клиенти;

Клиент, който предоставя потребителски интерфейс, изпълнява логиката на приложението, валидира данни, изпраща заявки към сървъра и получава отговори от него;

Мрежов и комуникационен софтуер, който комуникира между клиент и сървър, използвайки мрежови протоколи.

ДБ, по структур език SQL заявки (Structured Query Language), който е Индустриален стандартв света на релационните бази данни. Отдалечен сървърприема заявката и я препраща към SQL сървъра на база данни. SQL сървър – специална програма, който управлява отдалечената база данни. SQL сървърът осигурява интерпретация на заявката, нейното изпълнение в базата данни, генериране на резултата от заявката и доставката му до клиентското приложение. В този случай ресурсите на клиентския компютър не участват във физическото изпълнение на заявката; клиентският компютър само изпраща заявка до базата данни на сървъра и получава резултата, след което го интерпретира като необходимо и го представя на потребителя. Тъй като резултатът от заявката се изпраща до клиентското приложение, само данните, от които клиентът се нуждае, „пътуват“ през мрежата. В резултат на това натоварването на мрежата намалява. Тъй като заявката се изпълнява там, където се съхраняват данните (сървърът), няма нужда да се изпращат големи пакети от данни. В допълнение, SQL сървърът, ако е възможно, оптимизира получената заявка, така че да се изпълни за минимално време с най-малко разходи [[3.2], [3.3]]. системата е показана на фиг. 3.3.

Всичко това повишава производителността на системата и намалява времето, необходимо за изчакване на резултат от заявката. Когато заявките се изпълняват от сървъра, степента на сигурност на данните се повишава значително, тъй като правилата за целостта на данните са дефинирани в базата данни на сървъра и са еднакви за всички приложения, които използват тази база данни. Това елиминира възможността за определяне на противоречиви правила за поддържане на целостта. Мощният механизъм за транзакции, поддържан от SQL сървъри, прави възможно предотвратяването на едновременни промени в едни и същи данни от различни потребители и предоставя възможност за връщане към първоначалните стойности, когато правите промени в базата данни, които са приключили необичайно [[3.2], [ 3.3]].

Ориз. 3.3.Архитектура клиент-сървър

• Има локална мрежа, състояща се от клиентски компютри, на всеки от които има инсталирано клиентско приложение за работа с базата данни.
• На всеки от клиентските компютри потребителите имат възможност да стартират приложението. Използвайки потребителския интерфейс, предоставен от приложението, той инициира извикване към СУБД, разположена на сървъра, за извличане/актуализиране на информация. За комуникация се използва специален език за заявки SQL, т.е. Само текстът на заявката се предава по мрежата от клиента към сървъра.
• СУБД инициира извиквания към данни, разположени на сървъра, в резултат на което цялата обработка на данни се извършва на сървъра и само резултатът от заявката се копира на клиентския компютър. Така СУБД връща резултата на приложението.

Нека да разгледаме как изглежда разделянето на функциите между сървъра и клиента.

• Функции на клиентското приложение:
  • Изпращане на заявки към сървъра.
  • Интерпретация на резултатите от заявките, получени от сървъра.
  • Представяне на резултатите на потребителя под някаква форма (потребителски интерфейс).
• Функции от страна на сървъра:
  • Получаване на заявки от клиентски приложения.
  • Тълкуване на искания.
  • Оптимизиране и изпълнение на заявки към база данни.
  • Изпращане на резултатите към клиентското приложение.
  • Осигуряване на система за сигурност и контрол на достъпа.
  • Управление на целостта на базата данни.
  • Внедряване на стабилност на многопотребителски режим на работа.

Така наречените „индустриални“ СУБД работят в архитектурата клиент-сървър. Те се наричат ​​индустриални, защото СУБД от този клас може да осигури работата информационни системимащаба на средно и голямо предприятие, организация, банка. Категорията индустриални СУБД включва MS SQL Server, Oracle, Gupta, Informix, Sybase, DB2, InterBase и редица други [[3.2]].

По правило SQL сървърът се поддържа от отделен служител или група служители (администратори на SQL сървър). Те управляват физическите характеристики на базите данни, извършват оптимизация, конфигурация и предефиниране различни компонентибази данни, създаване на нови бази данни, промяна на съществуващи и т.н., както и издаване на привилегии (разрешения за определено ниво на достъп до конкретни бази данни, SQL сървър) на различни потребители [[3.2]].

Нека да разгледаме основните предимства на тази архитектура в сравнение с файловата сървърна архитектура:

• Мрежовият трафик е значително намален.
• Намалява се сложността на клиентските приложения (по-голямата част от натоварването пада върху сървърната част) и следователно се намаляват изискванията за хардуерния капацитет на клиентските компютри.
• Наличие на специални софтуерен инструмент– SQL сървър – води до това, че значителна част от задачите по проектиране и програмиране вече са решени.
• Значително се повишава целостта и сигурността на базата данни.

Недостатъците включват по-високи финансови разходиза хардуер и софтуер, както и фактът, че голям брой клиентски компютри, разположени на различни места, създават определени трудности с навременна актуализацияклиентски приложения на всички клиентски компютри. Архитектурата клиент-сървър обаче се е доказала на практика, в понастоящемИма голям брой бази данни, изградени в съответствие с тази архитектура.

3.4. Тристепенна (многостепенна) клиент-сървър архитектура.

Три връзки (в някои случаи много връзки) архитектура(N-ниво или много- тристепенна архитектура? Сега, когато бизнес логиката се промени, вече няма нужда да променяте клиентските приложения и да ги актуализирате за всички потребители. Освен това изискванията за потребителско оборудване са максимално намалени.

И така, в резултат на това работата е структурирана, както следва:

• Базата данни под формата на набор от файлове се намира на твърдия диск на специално предназначен компютър (мрежов сървър).
• СУБД също се намира на мрежовия сървър.
• Има специално предназначен сървър за приложения, на който се намира софтуерът за бизнес анализ (бизнес логика) [[3.1]].
• Има много клиентски компютри, всеки от които има инсталиран така наречения „тънък клиент“ - клиентско приложение, което реализира потребителския интерфейс.
• На всеки от клиентските компютри потребителите имат възможност да стартират приложение - тънък клиент. Използвайки потребителския интерфейс, предоставен от приложението, той инициира повикване към софтуера за бизнес разузнаване, разположен на сървъра на приложения.
• Сървърът на приложения анализира изискванията на потребителите и генерира заявки към базата данни. За комуникация се използва специален език за заявки SQL, т.е. Само текстът на заявката се предава по мрежата от сървъра на приложения към сървъра на базата данни.
• СУБД капсулира в себе си цялата информация за физическата структура на базата данни, разположена на сървъра.
• СУБД инициира извиквания към данни, разположени на сървъра, в резултат на което резултатът от заявката се копира на сървъра на приложения.
• Сървърът на приложения връща резултата на клиентското приложение (потребител).
• Приложението, използвайки потребителския интерфейс, показва резултата от заявките.