здрасти Днес ще научим за тема, която е много интересна и най-важното, много търсена на пазара на труда: ПОЧИВКАТА. Ще разделим нашия преглед на REST на три части:
В първата част ще разгледаме историята на REST и ще опишем принципите, на които се основава REST.
Във втория ще разгледаме How се осъществява комуникацията между клиент и сървър чрез HTTP протокола.
В третия ще напишем малко RESTful приложение, което ще тестваме с помощта на програма, наречена „Пощальон“.
Статията е предназначена за читатели, запознати със следните термини:
HTTP
URL и URI
JSON и (в по-малка степен) XML
Инжектиране на зависимост
Част 1. Какво е REST?
REST, Howто много в света на ИТ, е акроним. Произлиза от „REpresentational State Transfer“ . Това е архитектурен стил за взаимодействие между компоненти на разпределена система в компютърна мрежа. Просто казано, REST определя стила за взаимодействие (обмен на данни) между различни компоненти на системата, всеки от които може да бъде физически разположен на различни места. Този архитектурен стил е последователен набор от ограничения, спазвани при проектирането на разпределена система. Тези ограничения понякога се наричат ръководни принципи на REST. Не са много, само 6. За тях ще говорим малко по-късно.
Приложенията, създадени с оглед на принципите на REST, т.е. тези, които не нарушават ограниченията на REST, се наричат „RESTful“.
История на REST
Терминът REST е въведен от Рой Филдинг, един от създателите на HTTP протокола, в неговата докторска степен. дисертация, озаглавена „Архитектурни стилове и проектиране на мрежови софтуерни архитектури“ през 2000 г. Въпреки че терминът REST все още може да се нарече млад, концепцията, която представлява, лежи в самата сърцевина на World Wide Web. Няма да се гмурнем дълбоко в историята на термина. Ако искате да се потопите в първичните източници, погледнете дисертацията на Филдинг .
REST ограничения и принципи
Както беше посочено по-горе, REST определя How компонентите на една разпределена система трябва да взаимодействат един с друг. По принцип това се случва чрез процес на заявка-отговор. Компонентът, който изпраща заявката, се нарича клиент , а компонентът, който обработва заявката и изпраща отговор на клиента, се нарича сървър. Заявките и отговорите най-често се изпращат по HTTP протокола. HTTP означава HyperText Transfer Protocol. Обикновено сървърът е няHowво уеб приложение. Клиентът може да бъде почти всичко. Например мобилно приложение, което иска данни от сървър. Или браузър, който изпраща заявки от уеб page към сървър, за да изтегли данни. Приложение A може да поиска данни от Приложение B. В този случай A е клиент по отношение на B, а B е сървър по отношение на A. В същото време A може да обработва заявки от B, C, D и т.н. В този случай приложение A е едновременно сървър и клиент. Всичко зависи от контекста. Едно е сигурно: компонентът, който изпраща заявката, е клиентът. Компонентът, който получава, обработва и отговаря на заявка, е сървърът. Въпреки това, не всяка система, чиито компоненти комуникират чрез процес на заявка-отговор, е RESTful система. За да се счита една система за RESTful, тя трябва да отговаря на шестте REST ограничения:
1. Архитектура клиент-сървър
Това ограничение се отнася до разделянето на загрижеността. Необходимо е да се отделят изискванията на клиентския интерфейс от изискванията на сървъра, който съхранява данните. Това ограничение прави клиентския code по-преносим към други платформи, а опростяването на сървърната страна подобрява скалируемостта на системата. Пequalsето на разграничение между „клиента” и „сървъра” позволява те да бъдат разработени независимо един от друг.
2. Без гражданство
Архитектурата RESTful изисква да бъдат изпълнени следните условия. В периода между заявките сървърът не трябва да съхранява информация за състоянието на клиента и обратно. Всички заявки от клиента трябва да бъдат съставени по начин, който предоставя на сървъра цялата необходима информация за изпълнение на заявката. Така Howто сървърът, така и клиентът могат да „разберат“ всяко получено съобщение, без да разчитат на предишни съобщения.
3. Кешируеми
Клиентите могат да кешират отговорите на сървъра. Те от своя страна трябва изрично or косвено да бъдат обозначени като кеширани or некеширани, така че клиентите да не получават остарели or неправилни данни в отговор на последващи заявки. Правилното кеширане помага за пълното or частично елиминиране на някои взаимодействия клиент-сървър, като допълнително повишава производителността и скалируемостта на системата.
4. Единен интерфейс
Основните изисквания на RESTful архитектурата включват унифициран, унифициран интерфейс. Клиентът винаги трябва да разбира формата и addressите, които трябва да използва, когато изпраща заявка, а сървърът, от своя страна, също трябва да разбира формата, който трябва да използва, когато отговаря на клиентски заявки. Това последователно взаимодействие клиент-сървър, което описва Howво, къде, под Howва форма и How да се изпращат данни, е унифициран интерфейс.
5. Слоеве
Под слоеве имаме предвид йерархичната структура на мрежата. Понякога клиентът може да комуникира директно със сървъра, а понякога просто комуникира с междинен възел. Използването на междинни сървъри може да увеличи скалируемостта благодарение на балансирането на натоварването и разпределеното кеширане. Нека дадем пример. Представете си мобилно приложение, което е популярно в цял свят. Неразделна част от приложението включва зареждане на снимки. Неговите потребители са мorони, така че един сървър не може да се справи с такова голямо натоварване. Разделянето на системата на слоеве ще реши този проблем. Ако клиентът поиска картина от междинен възел, тогава междинният възел изисква картината от сървъра, който е най-малко зареден в момента, и връща картината на клиента. Ако кеширането се прилага правилно на всяко ниво на йерархията,
6. Код при поискване (по избор)
Това ограничение предполага, че клиентът може да разшири своята функционалност чрез изтегляне на code от сървъра под формата на аплети or скриптове.
Предимства на RESTful архитектура
Приложенията, които отговарят на всички гореспоменати ограничения, имат следните предимства: надеждност (няма нужда да запазвате състоянието на клиента, което може да бъде загубено)
производителност (поради използването на кеш)
мащабируемост
прозрачна комуникация
прости интерфейси
преносимост
способност за лесни промени
способност за развитие и адаптиране към новите изисквания
Ще разделим нашия преглед на REST на три части:
