Сәлеметсіз бе, бүгін біз еңбек нарығында өте қызықты, ең бастысы, сұранысқа ие тақырыпты - REST тақырыбын зерттейміз. Біз REST шолуын үш бөлікке бөлеміз:
Бірінші бөлімде біз REST тарихына тоқталып, REST негізделген принциптерді сипаттаймыз.
Екіншісінде HTTP протоколы арқылы клиент пен server арасындағы байланыстың қалай болатынын қарастырамыз.
Үшіншісінде біз Postman бағдарламасы арқылы сынақтан өткізетін шағын RESTful қосымшасын жазамыз.
Мақала келесі терминдермен таныс оқырманға арналған:
HTTP;
URL және URI;
JSON және аз дәрежеде XML;
Тәуелділік инъекциясы.
1-бөлім. REST дегеніміз не
REST, АТ әлеміндегі көптеген нәрселер сияқты, өкілдік мемлекетті тасымалдаудың аббревиатурасы болып табылады . Бұл компьютерлік желідегі бөлінген жүйе құрамдастарының өзара әрекеттесуінің архитектуралық стилі. Қарапайым тілмен айтқанда, REST жүйенің әртүрлі компоненттері арасындағы өзара әрекеттесу (деректер алмасу) стилін анықтайды, олардың әрқайсысы физикалық түрде әртүрлі орындарда орналасуы мүмкін. Бұл архитектуралық стиль бөлінген жүйені жобалау кезінде ескерілетін шектеулердің дәйекті жиынтығын білдіреді. Бұл шектеулер кейде REST принциптері деп аталады. Олардың саны көп емес, бар болғаны 6 дана. Олар туралы сәл кейінірек айтатын боламыз.
REST ескере отырып жасалған қолданбалар, яғни. REST қойған шектеулерді бұзbyteындар RESTful деп аталады.
REST тарихы
REST терминін HTTP протоколын жасаушылардың бірі Рой Филдинг 2000 жылы «Архитектуралық стильдер және желіге негізделген бағдарламалық жасақтама архитектураларының дизайны» атты докторлық диссертациясында енгізді. REST термині әлі де жас деп айта аламыз, бірақ оның тұжырымдамасы Бүкіләлемдік Интернеттің негізінде жатыр. Біз бұл терминнің шығу тарихына терең үңілмейміз. Түпнұсқа дереккөздермен танысқыңыз келсе, Филдингтің диссертациясын қараңыз .
REST шектеулері мен принциптері
Жоғарыда айтылғандай, REST бөлінген жүйенің құрамдас бөліктері бір-бірімен қалай әрекеттесу керектігін анықтайды. Жалпы, бұл сұрау-жауап арқылы болады. Сұранысты жіберетін компонент клиент деп аталады ; Сұранысты өңдейтін және клиентке жауап жіберетін компонент server деп аталады . Сұраулар мен жауаптар көбінесе HTTP (HyperText Transfer Protocol) арқылы жіберіледі. Әдетте server веб-бағдарламаның қандай да бір түрі болып табылады. Клиент кез келген нәрсе емес, өте көп болуы мүмкін. Мысалы, serverден деректерді сұрайтын мобильді қосымша. Немесе деректерді жүктеу үшін веб-беттен serverге сұрау жіберетін шолғыш. А қолданбасы В қосымшасынан деректерді сұрай алады. Сонда А В қолданбасына қатысты клиент, ал В А serverіне қатысты server. Сонымен бірге А C, D, D, т.б. сұраныстарды өңдей алады. Бұл жағдайда А қосымшасы әрі server, әрі клиент болып табылады. Мұның бәрі контекстке байланысты. Бір нәрсе анық: сұранысты жіберетін компонент клиент болып табылады. Сұранысты қабылдайтын, өңдейтін және оған жауап беретін компонент server болып табылады. Дегенмен, компоненттері сұрау-жауап арқылы байланысатын әрбір жүйе REST (немесе RESTful) жүйесі емес. Жүйені RESTful деп санау үшін ол алты REST шектеуіне «сәйкес» болуы керек:
1. Архитектураны клиент-server үлгісіне келтіру
Бұл шектеудің негізі қажеттіліктерді саралау болып табылады. Клиент интерфейсінің қажеттіліктерін деректерді сақтайтын serverдің қажеттіліктерінен бөлу қажет. Бұл шектеу клиенттік codeтың басқа платформаларға тасымалдануын арттырады, ал server бөлігін жеңілдету жүйенің ауқымдылығын жақсартады. «Клиент» мен «server» арасындағы айырмашылық олардың бір-бірінен тәуелсіз дамуына мүмкіндік береді.
2. Шарттың болмауы
REST архитектурасы келесі шарттың орындалуын талап етеді. Сұраулар арасында server клиенттің күйі туралы ақпаратты сақтаудың қажеті жоқ және керісінше. Клиенттің барлық сұраулары server сұранысты аяқтау үшін барлық қажетті ақпаратты алатындай құрылымдалу керек. Осылайша, server де, клиент те алдыңғы хабарламаларға сүйенбестен алынған кез келген хабарламаны «түсіне алады».
3. Кэштеу
Клиенттер server жауаптарын кэштей алады. Бұлар, өз кезегінде, кэштелетін немесе кэштелмейтін ретінде анық немесе жанама түрде белгіленуі керек, осылайша клиенттер кейінгі сұрауларға жауап ретінде ескірген немесе дұрыс емес деректерді алмайды. Кэштеуді дұрыс пайдалану кейбір клиент пен serverдің өзара әрекеттесуін толығымен немесе ішінара жоюға көмектеседі, жүйе өнімділігі мен кеңейтілуін одан әрі арттырады.
4. Интерфейстің біркелкілігі
REST архитектурасының негізгі талаптары бірыңғай, біркелкі интерфейсті қамтиды. Клиент сұранысты қай форматта және қандай мекенжайларға жіберу керектігін әрқашан түсінуі керек, ал server өз кезегінде клиенттің сұрауларына қандай форматта жауап беру керектігін түсінуі керек. Бұл нені, қайда, қандай пішінде және қалай жіберу керектігін сипаттайтын клиент пен server әрекеттестігінің бірыңғай форматы және біртұтас интерфейс.
5. Қабаттар
Қабаттар желілердің иерархиялық құрылымына жатады. Кейде клиент serverмен тікелей байланыса алады, ал кейде аралық түйінмен жай ғана байланыса алады. Аралық serverлерді пайдалану жүктемені теңестіру және бөлінген кэштеу арқылы масштабтауды арттыруы мүмкін. Мысал келтірейік. Бүкіл әлемде танымал мобильді қосымшаны елестетейік. Оның ажырамас бөлігі кескіндерді жүктеу болып табылады. Миллиондаған пайдаланушылар болғандықтан, бір server мұндай ауыр жүктемеге төтеп бере алмады. Жүйені қабаттарға бөлу бұл мәселені шешеді. Клиент аралық түйіннен суретті сұрайды, аралық түйін қазіргі уақытта ең аз жүктелген serverден суретті сұрайды және суретті клиентке қайтарады. Егер кэштеу мұнда иерархияның әрбір деңгейінде дұрыс қолданылса, жүйенің жақсы масштабтауға қол жеткізуге болады.
6. Сұраныс бойынша code (міндетті емес шектеу)
Бұл шектеу клиенттің serverден codeты апплет немесе сценарий түрінде жүктеп алу арқылы өзінің функционалдығын кеңейте алатынын білдіреді.
REST артықшылықтары
Жоғарыда аталған шектеулердің барлығына сәйкес келетін қолданбалардың келесі артықшылықтары бар: сенімділік (жоғалуы мүмкін клиент күйі туралы ақпаратты сақтаудың қажеті жоқ);
GO TO FULL VERSION