RESTге сереп салуу. 1-бөлүк: REST деген эмне

Саламатсыздарбы, бүгүн биз эмгек рыногунда абдан кызыктуу, эң негизгиси суроо-талапка ээ болгон теманы - RESTти изилдейбиз. Биз RESTтин жалпы көрүнүшүн үч бөлүккө бөлөбүз:

1. Биринчи бөлүктө биз RESTтин тарыхына токтолуп, REST негизделген принциптерди сүрөттөп беребиз.

2. Экинчиден, HTTP протоколу аркылуу кардар менен serverдин ортосунда кандай байланыш пайда болгонун карап чыгабыз.

3. Үчүнчүсүндө, биз кичинекей RESTful тиркемесин жазабыз, аны Postman программасын колдонуп сынайбыз.

Макала төмөнкү терминдерди жакшы билген окурмандар үчүн арналган:

• HTTP;
• URL жана URI;
• JSON жана бир аз XML;
• Көз карандылык инъекциясы.

1-бөлүк. REST деген эмне

REST, IT дүйнөсүндөгү көптөгөн нерселер сыяктуу эле, Мамлекеттик Өкүлчүлүккө өткөрүп берүү деген сөздүн кыскартылган түрү . Бул компьютер тармагындагы бөлүштүрүлгөн системанын компоненттеринин ортосундагы өз ара аракеттенүүнүн архитектуралык стor. Жөнөкөй сөз менен айтканда, REST системанын ар кандай компоненттеринин ортосундагы өз ара аракеттенүүнүн (маалымат алмашуу) стorн аныктайт, алардын ар бири физикалык жактан ар башка жерлерде болушу мүмкүн. Бул архитектуралык стил бөлүштүрүлгөн системаны долбоорлоодо эске алынган чектөөлөрдүн ырааттуу топтомун билдирет. Бул чектөөлөр кээде REST принциптери деп аталат. Алардын саны көп эмес, болгону 6 даана. Биз алар жөнүндө бир аз кийинчерээк сүйлөшөбүз.

REST тарыхы

REST термини HTTP протоколун түзүүчүлөрдүн бири Рой Филдинг тарабынан 2000-жылы "Архитектуралык стилдер жана тармакка негизделген программалык архитектуралардын дизайны" деген докторлук диссертациясында киргизилген. REST термини али жаш деп айта алабыз, бирок анын концепциясы Бүткүл дүйнөлүк желенин негизин түзөт. Биз бул терминдин келип чыгыш тарыхына терең сүңгүп кирбейбиз. Эгер сиз түпнуска булактарга сүңгүүнү кааласаңыз, Филдингдин диссертациясын караңыз .

REST чектөөлөрү жана принциптери

Жогоруда айтылгандай, REST бөлүштүрүлгөн системанын компоненттери бири-бири менен кандайча иштеши керектигин аныктайт. Жалпысынан алганда, бул суроо-жооп аркылуу болот. Сурам жөнөтүүчү компонент кардар деп аталат ; Сурамды иштеп чыгуучу жана кардарга жооп жөнөтүүчү компонент server деп аталат . Сурамдар жана жооптор көбүнчө HTTP (HyperText Transfer Protocol) аркылуу жөнөтүлөт. Адатта, server бул веб-тиркемелердин кандайдыр бир түрү. кардар эч нерсе эмес, абдан көп болушу мүмкүн. Мисалы, serverден маалыматтарды сураган мобилдик тиркеме. Же маалыматты жүктөө үчүн веб-баракчадан serverге суроо-талаптарды жөнөтүүчү браузер. А тиркемеси В тиркемесинен берorштерди сурай алат. Анда А — Вге карата кардар, ал эми В — Ага карата 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тин артыкчылыктары

Жогорудагы бардык чектөөлөргө туура келген тиркемелер төмөнкү артыкчылыктарга ээ: ишенимдүүлүк (кардардын абалынын маалыматын сактоонун кереги жок, алар жоголуп кетиши мүмкүн);

• аткаруу (кэшти колдонуудан улам);
• масштабдуулугу;
• өз ара аракеттенүү системасынын ачыктыгы;
• интерфейстердин жөнөкөйлүгү;
• компоненттердин көчмө жөндөмдүүлүгү;
• өзгөртүүлөрдү киргизүү жеңил;
• жаңы талаптарга көнүү, өнүгүү жөндөмдүүлүгү.

2-бөлүк: кардар менен serverдин ортосундагы байланыш 3-бөлүк: Spring Bootто RESTful кызматын түзүү