full-document.pdf

ss Основи на веб програмирање со користење на Spring рамката re og Ристе Стоjанов, Сашо Граматиков, Милош pr Jовановиќ, Димитар Траjанов in k or W Скопjе, маj 2023 Акроними AOP - Aspect Oriented Programming API - Application Programming Interface APNG - Animated PNG AVIF - AV1 Image File Format CRUD - Create, Read, Update, Delete CSRF - Cross-Site Request Forgery CSS - Cascading Style Sheets DI - Dependency Injection DIP - Dependency Inversion Principle DNS - Domain Name System ss EE - Enterprise Edition HTML - Hypertext Markup Language re HTTP - Hypertext Transfer Protocol HTTPS - Hypertext Transfer Protocol Secure og IANA - Internet Assigned Numbers Authority IDE - Integrated Development Environment IP - Internet Protocol pr ISP - Interface Segregation Principle JAR - Java ARchive JDBC - Java Database Connectivity in JDK - Java Development Kit JEE - Java Enterprise Edition JPA - Jakarta Persistence API JPQL - Java Persistence Query Language k JRE - Java Run-time Environment or JSE - Java Standard Edition JSON - JavaScript Object Notation W JSP - Java Server Pages JSTL - JSP Standard Tag Library JVM - Java Virtual Machine JWT - JSON Web Token LDAP - Lightweight Directory Access Protocol LSP - Liskov Substitution Principle MIME - Multipurpose Internet Mail Extensions MVC - Model-View-Controller OCP - Open-Closed Principle ORM - Object Relational Mapping ii POJO - Plain Old Java Object RFC - Request For Comments SOLID - Single Responsibility Principle, Open-Closed Principle, Liskov Substitution Principle, Interface Segregation Principle, Dependency Inversion Principle SQL - Structured Query Language SRP - Single Responsibility Principle SSH - Secure (Socket) Shell SSL - Secure Sockets Layer TCP - Transport Control Protocol UI - User Interface URI - Uniform Resource Identifier URL - Uniform Resource Locator ss VPN - Virtual Private Network WWW - World Wide Web re XML - Extensible Markup Language og pr in k or W iii Основи на веб програмирање со користење на Spring рамката Содржина Листа на слики v Листа на табели v ss 1 HTTP 5 re 1.1 HTTP комуникациjа........................... 7 1.2 Структура на URL адреса....................... 11 1.3 HTTP пораки............................... 12 og 1.4 HTTP верзии............ 1.5 HTTP методи.................................................. 14 15 pr 1.6 HTTP статусни кодови......................... 17 1.7 Полиња на HTTP заглавjе....................... 18 1.8 Колачиња................................. 19 1.9 HTTPS.................................. 20 in 1.10 Примери за HTTP комуникациjа................... 24 2 Основи на J2EE 34 k 2.1 Што е JEE и зошто е потребна?.................... 34 2.2 Сервлет контеjнер............................ 36 or 2.3 Сервлети................................. 40 2.3.1 Имплементациjа......................... 40 W 2.3.2 Регистрациjа на сервлети и пресликување.......... 42 2.3.3 Животен циклус на сервлет.................. 45 2.3.4 Обработка на барања од сервлети............... 46 2.3.5 Вежба: Имплементациjа на бизнис логика на сервлет.... 48 2.3.6 Интеракциjа помеѓу сервлети................. 53 2.4 Управување со состоjби......................... 61 2.4.1 Параметри и атрибути..................... 61 2.4.2 Работа со параметри и атрибути во апликациски опсег (ServletContext)......................... 62 2.4.3 Работа со податоци во сервлетски опсег (ServletConfig)... 68 iv 2.4.4 Работа со параметри и атрибути во опсег на барање.... 71 2.4.5 Работа со атрибути во сесиски опсег............. 75 2.4.6 Генерален преглед на параметри, атрибути и опсези на важење 82 2.4.7 Вежба: Работа со параметри и атрибути во опсези на апли- кациjа............................... 83 2.5 Филтри.................................. 94 2.5.1 Конфигурациjа на филтри................... 96 2.5.2 Имплементациjа на филтри.................. 100 3 Запознавање со Spring рамката 107 3.1 Spring рамка............................... 107 3.2 Дизаjн филозофиjа на Spring...................... 109 ss 3.2.1 SOLID принципи......................... 111 3.3 Вметнување зависности......................... 117 re 3.4 Инверзиjа на контролата со користење на Spring рамката..... 121 3.4.1 Регистрирање на бинови.................... 122 og 3.4.2 Животен циклус на биновите............... 3.4.3 Автоматско вметнување на зависности.......... 3.5 Опции за Конфигурирање во Spring...................... 125 127 130 pr 3.5.1 Животен век на биновите.................... 130 3.5.2 Конфигурациjа на вредности во Spring............ 131 3.5.3 Надворешни Конфигурации во Spring............. 132 3.5.4 Конфигурациски профили во Spring............. 133 in 3.6 Шаблони за флексибилен и одржлив дизаjн на веб апликации.. 134 3.6.1 MVC шаблон........................... 135 3.6.2 MVC шаблон за веб апликации................ 136 k 3.6.3 Слоевита архитектура...................... 137 or 3.6.4 Слоевит MVC шаблон за веб апликации........... 139 3.7 Преглед на основните концепти на Spring рамката......... 140 W 4 Spring MVC 141 4.1 Запознавање со Spring MVC...................... 141 4.1.1 WebApplicationContext..................... 143 4.2 Spring MVC анотирани контролери.................. 145 4.2.1 Мапирање со HTTP барањата преку анотациjата @RequestMapping........................ 148 4.2.2 Анотирани методи за справување со барања (Handler Methods)152 4.3 Spring REST............................... 168 4.3.1 Консумирање на податоци преку REST API......... 174 4.4 Процесирање на барање каj Spring MVC............... 176 4.5 Преглед на функционалностите од Spring MVC модулот...... 182 4.6 Пример контролери (Вежби)...................... 183 5 Работа со релациони бази на податоци 184 5.1 JPA обjектно-релационо пресликување................ 190 5.2 Ентитети................................. 191 5.2.1 Пресликување на табели.................... 193 5.2.2 Пресликување на колони.................... 194 5.2.3 Пресликување на примарни клучеви............. 195 5.2.4 Пресликување на основни типови на податоци........ 198 5.2.5 Енумерации............................ 198 ss 5.2.6 Транзитни полиња........................ 200 5.2.7 Вградени и вградливи обjекти................. 201 re 5.3 Релации.................................. 204 5.3.1 Релациjа „еден-кон-еден“.................... 206 og 5.3.2 Релациjа „повеќе-кон-еден“................... 5.3.3 Релациjа „еден-кон-повеќе“................... 5.3.4 Релациjа „повеќе-кон-повеќе“.................. 211 212 216 pr 5.4 Архитектура на JPA........................... 220 5.5 Користење на EntityManager...................... 223 5.6 Животен циклус на ентитет...................... 225 5.6.1 Креирање на управувани ентитети.............. 226 in 5.6.2 Вчитување и освежување на ентитет од базата на податоци 227 5.6.3 Ажурирање на ентитет..................... 228 5.6.4 Бришење на ентитет....................... 229 k 5.6.5 Методи за работа со перзистентен контекст......... 230 or 5.6.6 Извршување на кориснички дефинирани прашања..... 230 5.6.7 Вежба: креирање и користење на репозиториум за работа W со ентитети............................ 231 5.7 Работа со ентитети во релациjа.................... 237 5.7.1 Читање на ентитети во релациjа................ 237 5.7.2 Уредување на ентитети во релациjа.............. 239 5.7.3 Вежба: работа со ентитети во релациjа............ 243 5.8 Spring Data JPA............................. 255 5.8.1 Интерфеjси за репозиториуми................. 257 5.8.2 Конвенции за именување на методи.............. 263 5.8.3 Кориснички дефинирани барања............... 267 5.8.4 Вежба: Работа со Spring Data JPA............... 269 6 Заштита на веб апликации 279 6.1 Што сѐ треба да се заштитува?.................... 279 6.2 Напади на веб апликации........................ 282 6.2.1 Вметнување на SQL....................... 282 6.2.2 Cross-site scripting........................ 283 6.2.3 Фалсификување барања меѓу страници (Cross-Site Request Forgery – CSRF)......................... 283 6.3 Основи на безбедност на системи................... 284 6.3.1 Терминологиjа за безбедност.................. 284 6.3.2 Процеси во безбедност..................... 285 6.4 Заштита на веб апликации со Spring Security............. 288 6.4.1 Процес на автентикациjа и авторизациjа каj Spring Security 295 ss 6.4.2 Синџир со сигурносни филтри................. 306 6.4.3 Автентикациjа со Spring Security............... 308 re 6.4.4 Авторизациjа со Spring Security................ 319 6.4.5 Преглед на Spring Security функционалности........ 323 А Полиња на HTTP заглавjе og 325 pr Б Обjекти за HTTP барање и одговор 331 Б.1 HttpServletRequest............................ 331 Б.2 HttpServletResponse........................... 333 Б.3 Правила за повеќекратни пресликувања на сервлети........ 335 in Б.4 Дефинициjа на параметри на сервлети................ 335 Б.5 Конфигурациjа на редослед на вчитување на сервлети....... 337 Б.6 Контекстни настани и слушачи на настани.............. 337 k Б.7 Настани и слушачи на настани за барање.............. 341 Б.8 Животен век на сесиjа......................... 342 or Б.9 Пристап до параметри за сесиjа.................... 343 Б.10 Настани и слушачи на настани за сесии............... 343 W В Lombok 345 Основи на веб програмирање со користење на Spring рамката Листа на слики 1-1 Клиент-сервер архитектура на веб саjт................. 5 1-2 Клиент-сервер архитектура на веб апликациjа............ 6 1-3 Животот на едно HTTP барање..................... 10 ss 1-4 Анатомиjа на URL адреса........................ 12 1-5 Структура на HTTP барање....................... 13 re 1-6 Структура на HTTP одговор...................... 13 1-7 Генерирање на дигитален сертификат................. 22 1-8 Валидациjа на дигитален сертификат................. 22 1-9 1-10 og Воспоставување на SSL врска...................... Пример за HTTP комуникациjа помеѓу клиент и сервер со GET 25 pr барање................................... 26 1-11 Пример за HTML форма за генерирање на POST барање..... 30 1-12 Пример за HTTP комуникациjа помеѓу клиент и сервер со POST барање................................... 31 in 2-1 Опслужување на барање за динамички веб саjт (апликациjа)... 35 2-2 Животен циклус на еден проект.................... 39 k 2-3 Диjаграм на животен циклус на сервлет............... 46 2-4 Процес на опслужување на барање за динамички ресурс од сервлет or контеjнер................................. 47 2-5 Процес на опслужување на барање за динамички ресурс од сервлет W контеjнер................................. 48 2-6 Диjаграм на животен циклус на сервлет............... 54 2-7 Метод forward()............................. 59 2-8 Метод include()............................. 60 2-9 Преглед на карактеристики на атрибути и параметри....... 62 2-10 Преглед на животен век на ServletContext и неговите параметри 67 2-11 Преглед на животен век на ServletConfig и неговите параметри. 70 2-12 Преглед на животен век на ServletConfig и неговите параметри. 71 2-13 Преглед на HttpServletRequest и неговите параметри и атрибути. 74 2-14 Преглед на HttpSession и неговите атрибути............. 80 viii 2-15 Преглед на HttpSession и неговите атрибути............. 82 2-16 Преглед на елементи на сервлет контеjнер со параметри и атрибути на различни опсези........................... 84 2-17 Почетна состоjба на апликациjата................... 89 2-18 Состоjба на апликациjата откако ќе се повика "/s1?page=1".... 90 2-19 Состоjба на апликациjата откако ќе се повика "/s2?page=2".... 91 2-20 Состоjба на апликациjата откако ќе се повика "/s3"........ 92 2-21 Состоjба на апликациjата откако повторно ќе се повика "/s1?page=1" 93 2-22 Состоjба на апликациjата откако повторно ќе се повика "/s1?page=1" од различен корисник.................. 93 2-23 Претпроцесирање и постпроцесирање на барање и одговор со ко- ристење на филтри........................... 96 ss 2-24 Редослед на извршување на код од филтри при обработка на бара- ње..................................... 105 re 2-25 Комплетен преглед на управувани компоненти, параметри и атри- бути.................................... 106 3-1 3-2 og Модули од Spring рамката......... Зависности на модулите од Spring рамката............................ 109 110 pr 3-3 Животен циклус на Spring бинови................... 126 3-4 MVC шаблон............................... 135 3-5 MVC шаблон за веб апликации.................... 136 3-6 Слоевит MVC шаблон за веб апликации............... 139 in 4-1 Хиерархиjа на контексти каj Spring MVC............... 144 4-2 Процесирање на барање каj Spring MVC............... 177 k 4-3 Припрема на барање каj Spring MVC................. 178 4-4 Извршување на HandlerExecutionChain................ 180 or 4-5 Спраување со исклучоци, исцртување на прегледот и завршување на процесирањето............................ 181 W 5-1 Апстракциjа на податоци при работа со бази на податоци..... 189 5-2 Обjектно-релационо пресликување на класа во табела....... 191 5-3 Табела добиена од пресликување на ентитетот Product....... 193 5-4 Табела добиена од пресликување на ентитетот Product....... 203 5-5 Табела добиена од пресликување на ентитетот Company со редефи- нициjа на своjства на вградлива класа Address............ 204 5-6 Табели добиени од пресликување на ентитетитети Customer и Address со врска еден-кон-еден..................... 207 5-7 Шематски приказ на дефинициjа за двонасочна релациjа еден-кон- еден.................................... 210 5-8 Табели добиени од пресликување на ентитетите Order и Customer со врска повеќе-кон-еден.......................... 212 5-9 Табели добиени од пресликување на ентитетите Customer и Order со еднонасочна врска еден-кон-повеќе.................. 214 5-10 Шематски приказ на дефинициjа за еднонасочна и двонасочна ре- лациjа еден-кон-повеќе......................... 216 5-11 Табели добиени од пресликување на ентитетите Product и Category со еднонасочна врска повеќе-кон-повеќе............... 217 5-12 Шематски приказ на дефинициjа за двонасочна релациjа повеќе- кон-повеќе................................ 219 ss 5-13 Составни компоненти на архитектурата на JPA........... 220 5-14 Модел на животен циклус на ентитет................. 225 re 5-15 Преглед на Spring Data модули.................... 256 5-16 Преглед на репозиториуми....................... 261 6-1 og 5-17 Споредба на методи од JpaRepository и JPA............. Процес на автентикациjа........................ 262 286 pr 6-2 Процес на авторизациjа......................... 287 6-3 Преглед на заштита со Spring Security................ 289 6-4 Повикување на сигурносните филтри во стандардно сценарио.. 291 6-5 Повикување на сигурносните филтри при исклучок или неиспол- in нување на безбедносни услови..................... 292 6-6 Повеќе синџири со филтри....................... 293 6-7 Преглед на сигурносните филтри од Spring Security модулот... 298 k 6-8 Структура на SecurityContextHolder.................. 299 or 6-9 Обработка на барања од ExceptionTranslationFilter......... 301 6-10 Обработка на барања од DefalutLoginPageGeneratingFilter за сцена- риjа без и со конфигурирана предефинирана патека за логирање W....................................... 303 6-11 Обработка на барања од RememberMeAutehenticationFilter.... 306 6-12 Структура на ProviderManager..................... 310 6-13 Автентикациjа со ProviderManager................... 312 6-14 DaoAuthenticationProvider....................... 316 6-15 Обработка на барање со акредитиви за автентикациjа преку имп- лементациjа на AbstractAuthenticationProcessingFilter....... 319 Основи на веб програмирање со користење на Spring рамката Листа на табели 1.1 Опис на HTTP методите. Секое барање покраj метод содржи и ресурс коj се бара од серверот...................... 16 1.2 Опис на HTTP статусните кодови. Секоj одговор од серверот ss содржи точно еден статусен код..................... 17 3.1 Модули од Spring рамката....................... 108 re 5.1 Клучни зборови за дефинирање на пребарувања преку имиња на методи во Spring Data.......................... 265 5.2 og Клучни зборови за дефинирање на пребарувања преку имиња на методи во Spring Data.......................... 266 pr 5.3 Клучни зборови за модифицирање на пребарувања преку имиња на методи во Spring Data........................ 266 in k or W xi Основи на веб програмирање со користење на Spring рамката Ваш придонес за книгата Почитувани студенти, Оваа книга е во работна верзиjа и е подложна на постоjани промени. Со цел да стигнеме до финална и подобрена верзиjа за издавање, потребни ни се вашите ss забелешки и мислења. На формата на овоj линк https://forms.office.com/e/ ALLgyNxFqz?origin=lprLink ќе можете да ги внесете грешките кои што сте ги re пронашле, но исто така и проблемите со кои сте се соочиле во текот на читање- то. Секако, добредоjдено ќе биде вашето генерално мислење за секоjа глава, без разлика дали е позитивно или негативно. Целта е да се направи учебник наме- og нет за вас, студентите, па затоа вашето мислење и сугестии во голема мера ќе придонесат кон остварување на таа цел. pr Од авторите. in k or W 1 Основи на веб програмирање со користење на Spring рамката Предговор Во дигиталниот и поврзан свет, глобалниот пристап до информации и електорн- ски услуги (е-пошта, е-трговиjа, е-банкарство, е-здравство, социjални мрежи и сл.) се неизбежен и неопходен дел од нашето секоjдневие. Додека Интернетот, ка- ss ко глобална мрежа на поврзани компjутери, ни jа обезбедува инфраструктурата за користење на овие сервиси и пристап до информациите, за нивната имплемен- re тациjа е потребно да се развиjат веб апликации кои ќе генерираат динамички содржини прилагодени на нашите барања и преференци. Веб апликациите се хостирани на сервери со кои едноставно остваруваме интеракциjа преку веб пре- og листувачите, без разлика дали станува збор за пристап преку персонален ком- пjутер или паметен телефон. Токму поради нивната сестраност и едноставност pr за употреба, веб апликациите неминовно ги потиснуваат традиционалните деск- топ апликации. Тие се причина да се креира сосема нова бизнис околина во коjа секоjденвно се поjавуваат нови сервиси за кои сме сведоци дека предизвикуваат значителни промени во секоjдневниот начин на функционирање. Оттука, потре- in бата за развивање на нови веб апликации како и за подобрување и одржување на тековните веб апликации е во вртоглав раст. Иако содржините на динамичките страници од веб апликациите кои се доста- k вуваат до корисниците се базираат на стандардни технологии како што се HTML or за дефинирање на елементите на страниците, CSS за дефинирање на нивниот изглед и Javascript за подобрување на однесувањето и интеракциjата со краjни- от корисник, постоjат различни програсмки jазици и работни рамки кои може W да се користат за развивање на веб апликации како што се Jава, PHP, Python, C#, Node.js, Ruby итн. Изборот на jазик зависи од многу фактори поврзани со апликациjата, но и од личната преференца на развивачот на софтвер. За веб апликациите во оваа книга ќе го користиме програмскиот jазик Jава, бидеjќи е еден од наjраспространетите jазици кога станува збор за развоj на веб апли- кации. Дополнително, во рамките на оваа книга ќе биде разработена и Spring рамката, коjа овозможува брз и флексибилен развоj на сигурни веб апликации. Оваа рамка е избрана поради широката распространетост (особено во нашата држава), следењето на наjдобрите практики за градење на сигурени и одржливи 2 Основи на веб програмирање со користење на Spring рамката веб апликации, како и огромната зедница коjа помага во надминување на сите потенциjални предизвици и проблеми. Сепак, за да овозможи рапиден развоj на веб апликации, Spring рамката абстрахира голем дел од деталите кои се неоп- ходни за да се разбере суштината на развоjот на веб апликациите. Поради тоа, во оваа книга се обработуваат и фундаменталните J2ЕЕ технологии над кои е изградена Spring MVC библиотеката за развоj на веб апликации. На овоj начин, читателите на оваа книга ќе се здобиjат со вештини за ефикасен развоj на веб ап- ликации со Spring рамката, но ќе бидат опремени и со фундаменталните знаења за да можат jа разберат како детално се извршуваат кодот коj го напишале. Книгата го сублимира долгодишното искуството на авторите во едукативна и апликативна деjност од областа на веб програмирање. Во текот на овоj период, авторите ги согледуваат главните потешкотии со кои се сретнуваат студентите ss при развивањето на веб апликациите и побарувањата на индустриjата за под- готвени кадри кои ќе можат самостоjно да развиjат веб апликации. Затоа во re континуитет го прилагодуваат материjалот со цел да го доближат до студенти- те на наjедноставен и наjразбирлив начини, но истовремено и да одговорат на og предизвикот да ги подготват да бидат конкурентни на пазарот на труд. Токму затоа, книгата е замислена како основно и единствено помагало за совладувањето на комплетниот процес на развивање на веб апликации на едноставен и сликови- pr от начнин, елиминираjќи jа потребата читателот да троши дополнително време пребаруваjќи низ огромната база на достапни материjали во форма на учебници, блогови или форуми со цел да ги извлече базичните и неопходни концепти на in веб апликациите. Во оваа книга ќе бидат детлно опишани концептите на веб апликациите, тргнуваjќи од претпоставката дека читателите немаат претходно искуство на те- мата. Сепак, за да може успешно да се следи содржината, потребни се познавања k од обjектно ориентираното прогорамирање со програмскиот jазик Jава, основни or познавања маркирачкиот jазик HTML, работа со релациони бази на податоци и работа со интегрирани околини за развивање. W Книгата е наменета за студентите на Факултетот за информатички науки и компjутерско инженерство при Универзитетот „Св. Кирил и Методиj“ во Скопjе, запишани на студиските програми на кои се изучува курсот Веб програмирање како задолжителен или изборен предмет. Дополнително, книгата можат да jа користат студентите од останатите факултети од областа на иформатички на- уки ширум Северна Македониjа, професионални програмери и ентузиjасти кои сакаат да се оспособат да изработуваат веб апликации во рамката Spring. По совладување на метериjалот од кнгата, читателите ќе стекнат детално познавање на комуникациjата помеѓу клиент и сервер на апликациско ниво, познавање на рамката Spring и неjзините модули за работа со веб апликации и 3 Основи на веб програмирање со користење на Spring рамката ќе бидат во можност самостоjно да креираат безбедни веб апликации и сервиси поврзани со релациони бази на податоци. Цели на оваа книга се: Запознавање со суштинските концепти за развоj на веб апликации и нивно користење при креирање на практична апликациjа. Да jа модернизира Head First – Servlets and JSP Да ги селектира и поедностави основните концепти обработени во Pro Spring MVC with Web Flow. Да jа ги селектира и да ги постави во поширок контекст концептите де- финирани во Craig Walls - Spring in Action, 5th Edition (2018, Manning Publications). ss re og pr in k or W 4 Основи на веб програмирање со користење на Spring рамката Глава 1 HTTP ss World Wide Web, познат и како WWW, е еден од наjраспространетите сервиси на Интернет коj им овозможува на клиентите да пристапат до страниците на re веб саjтовите ширум светот. WWW го користи моделот клиент-сервер, каде еден сервер опслужува голем броj на клиенти. Иако WWW често се поистоветува со og Интернет, тоj преставува само еден од многуте мрежни сервиси кои го корис- тат Интернетот како мрежна инфраструктура преку коjа клиентите и серверите остваруваат меѓусебна комуникациjа. pr Под клиент (client, англ.) подразбираме компjутер, лаптоп, паметен телефон, итн. коj поседува веб прелистувач како апликациjа преку коjа испраќа барања за ресурси до серверот (server, англ.) и преку коjа ги прегледува добиените in содржини од одговорот од серверот (слика 1-1). Примери за веб прелистувачи се Chrome, Safari, Firefox, итн. k or W Слика 1-1: Клиент-сервер архитектура на веб саjт. Веб саjт е колекциjа од меѓусебно поврзани веб страници кои содржат текст, слики, видеа, аудио, скрипти и слично. Страниците претставуваат колек- циjа од статички ресурси со визуелни содржини кои корисниците можат да ги читаат и прегледуваат. Секоj ресурс е идентификуван преку уникатна адреса наречена Uniform Resource Locator (URL). Почетниот дел од оваа адреса се користи од прелистувачот за да го пронаjде серверот на коj се наоѓа ресурсот, а 5 Основи на веб програмирање со користење на Spring рамката остатокот од адресата се користи од самиот сервер за да го разликува бараниот ресурс од останатите ресурси кои ги поседува. Веб саjтовите им се достапни на корисниците преку веб сервер коj прет- ставува посебен софтвер инсталиран на компjутер со улога на веб сервер. Веб серверот ги содржи сите ресурси кои ги сочинуваат веб саjтовите, па неговата главна улога е да ги обработува барањата од корисниците за веб страници и да ги опслужи на тоj начин што ќе им ги достави сите ресурси кои ги побаруваат. Познати софтвери за веб сервери се Apache, Nginx, Microsoft IIS, итн. Освен веб саjтови, чии ресурси се статички и оттука секое барање за еден ист ресурс од различни клиенти резултира со иста доставена содржина, посто- jат и веб апликации чии ресурси имаат динамички карактер. Во зависност од податоците кои ги испраќа корисникот, веб серверот враќа динамички генери- ss рана содржина коjа веб прелистувачот му jа прикажува на корисникот на ист начин како и кога станува збор за веб страници. Бидеjќи веб серверите можат да re опслужуваат само статички ресурси, за да можат да работат со веб апликации тие треба да содржат дополнителен софтвер со улога на апликациски сервер за og динамичко генерирање на содржини. Познати софтвери за апликациски сервери се Tomcat, Glassfish, Nginx, Microsoft IIS, итн. Веб апликациите ги генерираат содржините врз основа на податоци сместени во бази на податоци, па затоа, ап- pr ликацискиот сервер комуницира со сервер на бази на податоци (слика 1-2). in k or Слика 1-2: Клиент-сервер архитектура на веб апликациjа. W Без разлика на типот на содржини кои се разменуваат помеѓу клиентот и серверот, или пак, за каков клиентски или серверски софтвер станува збор, за да се оствари успешна и недвосмислена комуникациjа, потребни се стандардизирани правила кои ќе ги почитуваат двете страни. Комуникациjата помеѓу клиентите и серверите е дефинирана во Hypertext Transfer Protocol (HTTP) протоколот. Овоj протокол овозможува пренесу- вање на означен текст (Hypertext) преку компjутерска мрежа. Протоколот дефи- нира дека комуникациjата помеѓу клиентот и серверот ќе се одвива на следниот начин: (1) клиентот креира и испраќа барање (request, англ.) до серверот, (2) серверот го процесира барањето и (3) го праќа резултатот назад до клиентот во 6 Основи на веб програмирање со користење на Spring рамката форма на одговор (response, англ.). Со тоа, велиме дека серверот го услужува (serve, serves, англ.) клиентот. Содржината на барањето и одговорот може да ва- рира, но генерално содржи означен текст и хипермедиjа1. HTTP протоколот го дефинира начинот на коj се структурираат и разменуваат овие пораки (барањето и одговорот) помеѓу клиентот и серверот, за да можат да бидат недвосмислено разбрани од двата уреди. Првично, HTTP протоколот наjмногу се користел за навигациjа низ множе- ство од веб страници. Во тоj момент, веб страниците претставуваат текстуални документи со означен текст, но набрзо нивната содржина се збогатува со хипер- медиjа, како што се слики, видеа и аудио содржини. Освен содржините кои имаат можност да ги пренасочат корисниците на други ресурси, страниците можат да содржат и форми со полиња за внес на податоци дефинирани во посебни HTML ss (Hyper Text Markup Language) ознаки. Откако корисникот ќе кликне на не- коj линк, прелистувачот генерира HTTP барање кон уникатната локациjа на re ресурсот, а веб серверот го доставува HTTP одговорот назад до прелистува- чот. Ако одговорот содржи HTML означен текст, прелистувачот ги обработува og HTML елементите од одговорот и ги прикажува на корисникот. На пример, ако станува збор за форма со полиња за внес на податоци, тогаш прелистувачот ги испраќа податоците во HTTP порака назначуваjќи го ресурсот коj треба да ги pr обработи. По обработка на пораката, веб серверот враќа нови податоци кои пре- листувачот ги прикажува. Со оглед на тоа што една HTML страница претставува означен текст коj може да содржи референцирани хипермедиjа елементи, откако in прелистувачот ќе jа обработи самата страница, за секоj хипермедиjа елемент се генерира посебно барање до серверот за негово преземање и прикажување. Спо- ред тоа, без разлика за каков тип на ресурс станува збор, комуникациjата преку HTTP протоколот се базира на генерирање HTTP барање до серверот кое k резултира со соодветен HTTP одговор. or 1.1 HTTP комуникациjа W Протоколот HTTP е претставник на апликацискиот слоj од свитата на протоколи TCP/IP врз кои е изграден модерниот Интернет. Овоj протокол е имплементиран во веб прелистувачите и веб серверите, криеjќи jа целата негова комплексност од краjните корисници. 1 Термините „означен текст“ и „хипермедиjа“ се однесуваат на текстуалната и мултимедиjал- ната содржина коjа е достапна на вебот. Префиксот хипер- во овоj контекст се интерпретира како „над“, односно текст и мултимедиjална содржина кои се супериорни во однос на отпеча- тениот текст, графика, аудио и видео содржината достапна надвор од вебот, поради можноста за нивно поврзување преку употребата на хиперлинкови. 7 Основи на веб програмирање со користење на Spring рамката За да започне HTTP комуникациjа, потребно е клиентот да испрати бара- ње за ресурс преку прелистувачот на неговиот компjутерски уред. Тоа наjчесто се изведува преку експлицитно внесување на URL адресата на ресурсот во веб прелистувачот или преку кликнување на некоj хиперлинк од веб страница. По- тоа, потребно е веб прелистувачот да го преведе доменското име на серверот, кое се содржи во почетниот дел на URL адресата, во конкретна Интернет прото- кол адреса (IP address, англ.) на веб серверот. За оваа цел се користи систем за разрешување на доменски имиња (Domain Name System - DNS), каде преку специjален DNS протокол се добива IP адреса. Потоа, прелистувачот jа користи оваа адреса за да кон неа jа испрати HTTP пораката (барањето). Со оглед на тоа што HTTP е протокол на апликациско ниво коj знае да об- работува само HTTP барања и одговори, но не и да ги пренесе низ недовер- ss ливиот Интернет, како транспортен протокол за доверлива размена на подато- ци помеѓу клиентот и серверот се користи протоколот за контрола на преносот re (Transmission Control Protocol - TCP). За да го испрати HTTP барањето, клиентот, односно неговиот веб прелистувач, наjпрвин отвора TCP конекциjа со og серверот. За да се отвори конекциjа, клиентот мора да jа специфицира IP адре- сата на серверот (коjа веќе jа добил од DNS сервисот) и дестинациската порта на коjа серверот слуша и очекува барања за конекции. Предефинирана порта за pr протоколот HTTP е портата 80. Ако портата е различна од предифинираната, тогаш таа мора да се наведе во самата URL адреса. Серверот jа прифаќа конекциjата, по што веб прелистувачот го испраќа ба- in рањето и преку истата конекциjа го добива одговорот назад. TCP го користи IP протоколот за да ги испрати TCP сегментите низ IP мрежата. TCP сегментите во своето тело ги содржат HTTP пораките. Ако една HTTP порака е преголема за да се смести во еден сегмент, тогаш таа се дели на помали парчиња кои се k разменуваат во посебни TCP сегменти. Поради недоверливоста на IP протоко- or лот (не гарантира дека IP пакетите ќе бидат доставени до дестинациjата), TCP протоколот се грижи евентуално изгубените сегменти да бидат препратени, па W со тоа му гарантира на HTTP протоколот дека сите пораки ќе бидат разменети во целост, истовремено контролираjќи jа брзината на трансфер да одговара на можностите на мрежата, клиентот и серверот. TCP сегментот коj го содржи HTTP барањето се предава на IP слоjот, коj по потреба го дели и испраќа во форма на пакети. Секоj пакет патува до серверот преку компjутерската мрежа така што попатните рутери го насочуваат до сер- верот врз основа на неговата IP адреса. Пакетот пристигнува каj серверот, тоj jа чита IP адресата, препознава дека пакетот е наменет за него, го отпакува и го препраќа на TCP слоjот. Во овоj слоj, врз основа на заглавиjата на TCP сегмен- тот, се одлучува коjа апликациjа ќе jа процесира пораката. Бидеjќи станува збор 8 Основи на веб програмирање со користење на Spring рамката за HTTP барање (дестинациска порта 80 во заглавието на TCP), тоа се препраќа до веб серверот коj комплетно jа разбира содржината на HTTP барањето, го об- работува и одредува коjа содржина ќе jа врати назад до клиентот преку HTTP одговор. При оваа комуникациjа, клиентот преку веб адресата точно прецизира на коj сервер се обраќа и коj ресурс точно го бара. Но, покраj адресата на ресурсот, клиентот го посочува и типот на барањето во зависност од тоа дали бара само ресурс или преку барањето испраќа и кориснички податоци во телото, како и дополнителни информации преку заглавjата на барањето кои му се потребни на серверот за негова правилна обработка. Некогаш може да се случи бараниот ресурс да не е достапен на серверот. Во овоj случаj, серверот мора да има начин да го извести клиентот дека бараниот ресурс не постои или можеби се наоѓа на друга ss локациjа. За оваа цел се користат статусни кодови кои на клиентот му помагаат да дознае што точно направил серверот со неговото барање. Покраj статусните re кодови, во заглавието на одговорот се испраќаат дополнителни информации кои му се потребни на прелистувачот за да ги обработи испратените податоци og во телото на одговорот. Подетално за содржината на пораките и статусните кодови ќе зборуваме во следните поглавjа. На слика 1-3 е даден пример за комуникациjа помеѓу клиент и сервер, каде pr во фокусот е само размената на пораки преку HTTP без да се навлегува во датали за протоколите на подолните нивоа. Во примерот, клиентот пристапува до страница на еден статички веб саjт, односно испраќа HTTP барање за датотеката in intro.html, коjа е сместена во директориум со патека wp на серверот со име www.courses.mk. Текот на комуникациjата е следен: 1. Клиентот jа внесува URL адресата http://www.courses.mk/wp/intro.html k на веб страницата во неговиот веб прелистувач. or 2. Веб прелистувачот го извлекува доменското име на серверот (www.courses.mk) од URL адресата и откако ќе го преслика името во W соодветна IP адреса, воспоставува TCP конекциjа со него, на порта 80. Потоа, креира HTTP барање и го испраќа преку воспоставената конекциjа. Барањето е од типот GET, што означува дека клиентот само го бара ресурсот без да праќа дополнителни податоци во неговото тело. Адресата на ресурсот во рамките на серверот е останатиот дел од URL адресата после доменското име, односно /wp/intro.html. 3. Серверот го прима барањето и jа користи адресата на ресурсот за да го лоцира во неговиот датотечен систем. Конкретно, jа бара датотеката со име intro.html зачувана во именикот за саjтот wp. 4. Серверот го лоцира ресурсот и креира HTTP одговор во чие тело jа сместу- 9 Основи на веб програмирање со користење на Spring рамката ss re og pr in k or W Слика 1-3: Животот на едно HTTP барање. ва содржината на датотеката intro.html. Датотеката содржи html елемен- ти за прикажување на обичен текст и на листа од ставки кои претставуваат хиперлинкови кои водат до други ресурси од саjтот. Серверот го испраќа и статусниот код 200 со опис OK за да му назначи на прелистувачот дека успешно го пронашол ресурсот коj го бара. Дополнително, серверот назна- 10 Основи на веб програмирање со користење на Spring рамката чува дека содржината на телото е html код со вкупна големина од 25.812 баjти. 5. Серверот го испраќа HTTP одговорот до клиентот преку воспоставената конекциjа. 6. Клиентот го прима HTTP одговорот. Неговиот прелистувач наjпрвин го чита статусот коj означува дека успешно е добиен бараниот ресурс, а потоа jа презема целата содржина од неговото тело. Врз основа на заглавието Content-Type заклучува дека таа содржина е html код коj го рендерира и го прикажува во формат разбирлив за корисникот. 1.2 Структура на URL адреса ss URL адресата претставува уникатен идентификатор на ресурси до кои може да се пристапи преку Интернет мрежата. Освен за адресирање на датотеки (.html, re.css,.js), URL се користи и за да се пристапи до разни Интернет сервиси (пр. REST сервис). URL е еден од клучните концепти на WWW и не се однесува og исклучиво на протоколот HTTP, туку може да се користи и за пристап до ресурси на Интернет мрежата преку други протоколи на апликациско ниво како што се HTTPS, FTP и FTPS. pr Секоjа URL адреса претставува низа од ASCII знаци коjа не смее да содржи празни места. Сепак, често е потребно низата да содржи знаци кои не припаѓаат на множеството ASCII, или пак содржи празни места. Во тоj случаj, секоj таков in знак се конвертира во URL-кодирана низа коjа се состои од знакот % проследен со два хексадецимални знаци кои го означуваат кодот за знакот. На пример, празното место се заменува со URL-кодираната низа %20 (или со знакот +). k URL адресата се состои од следните елементи (слика 1-4): or 1. Протокол - го означува протоколот преку коj ќе се преземе ресурсот. Кога станува збор за пристап до веб страници или веб апликации, се користат W протоколите HTTP или HTTPS. После името на протоколот се додава ни- зата :// 2. Домен на сервер - име на серверот коj го содржи ресурсот. Се користи за наоѓање на IP адресата преку DNS протоколот. 3. Порта - jа означува дестинациската порта на коjа серверот слуша за ко- некции. Се користи од страна на прелистувачот за да воспостави TCP ко- некциjа со серверот. Наjчесто се изоставува од URL адресата и во тоj случаj прелистувачот jа користи предефинираната порта: 80 за HTTP, односно 443 за HTTPS. 11 Основи на веб програмирање со користење на Spring рамката 4. Патека на ресурс - jа означува патеката на ресурсот во рамките на сер- верот. Оваа патека е релативна во однос на именикот коj е означен како локациjа за документите на веб серверот. 5. Низа за пребарување - Опционална низа коjа започнува со знакот ? после коjа следат парови клуч=вредност одвоени со знакот &. Секоj пар клуч=вредност претставува кориснички податок коj се испраќа до серверот. На слика 1-4 е даден пример за URL адреса во коjа како протокол за презе- мање на ресурсот се користи HTTPS. Ресурсот се наоѓа на сервер со доменско име www.courses.mk коj слуша на порта 443. Во рамките на серверот, ресурсот се наоѓа на патеката /programming/wp/index.html. Дополнително, во низата за пребарување прелистувачот го испраќа параметарот page со вредност 1 и size ss со вредност 2. re og Слика 1-4: Анатомиjа на URL адреса. pr 1.3 HTTP пораки in HTTP пораките имаат точно дефинирана структура и можат да бидат дефи- нирани како HTTP барање доколку потекнуваат од клиентот, или како HTTP одговор доколку потекнуваат од серверот. Структурата на барањето е дадена на k слика 1-5. Првата линиjа е задолжителен дел на барањето и се состои од: or Метод - го дефинира типот на барањето со што му дава информациjа на серверот како да ги третира податоците кои се испратени во остатокот од W пораката и како да jа обработи самата пораката; Адреса на ресурсот - релативна адреса на ресурсот коjа се состои од низа на знаци после доменското име на целата адреса; HTTP верзиjа - верзиjата на HTTP протоколот коjа jа поддржува пре- листувачот. Заглавjето на барањето (header fields, англ.) се состои од клуч-вредност па- рови кои го допрецизираат барањето или содржат информации за клиентот, со- држина коjа треба да се испроцесира од серверот, метаподатоци за содржината коjа се испраќа, итн. По заглавието следува празна линиjа и на краjот е телото 12 Основи на веб програмирање со користење на Spring рамката на барањето. Во зависност од типот на барањето, телото може да биде празно, односно да не постои. ss re Слика 1-5: Структура на HTTP барање. og Серверот одговара на клиентското барање преку испраќање на еден или по- pr веќе одговори, при што секоj од нив jа има структурата прикажана на слика 1-6. in k or W Слика 1-6: Структура на HTTP одговор. Почетната линиjа на одговорот се разликува во структурата од почетната линиjа на барањето. Таа се состои од: 13 Основи на веб програмирање со користење на Spring рамката HTTP верзиjа - верзиjата на HTTP протоколот коjа jа поддржува серве- рот. Серверот jа зема предвид верзиjата коjа jа испратил клиентот и до- колку поддржува повеќе верзии, jа испраќа наjвисоката верзиjа коjа jа поддржува клиентот. Ова поле е потребно за да клиентот и серверот го користат истиот jазик на комуникациjа; Статусен код - го означува статусот на одговорот. Се користи од страна на прелистувачот, за да знае на коj начин да го третира одговорот; Опис на статусен код - текстуален опис на статусот наменет за луѓето, коj носи дополнителни информации за статусот. 1.4 HTTP верзии ss HTTP е основен протокол за World Wide Web (WWW) уште од неговото поjаву- вање во 1989 година. Оттогаш претрпува неколку значаjни измени кои придоне- re суваат за подобрување на неговите перформанси и функционалности, во склад со растот на саjтовите, на мрежните и на веб технологиите. Постоjат неколку раз- og лични верзии: HTTP/0.9, HTTP/1.0, HTTP/1.1 и HTTP/2.0. HTTP/1.1 е првата стандардизирана и стабилна верзиjа коjа има наjмасовна употреба. Новитетите кои ги воведува оваа верзиjа се: pr можност за испраќање на повеќе барања преку иста TCP конекциjа, без таа да се затвора; in вклучување на комплетното множество на HTTP методи; преговарање за типот на содржини; компресиjа на заглавjа, итн. k Сепак, со растот на обемот на веб странците и мултимедиските содржини кои or се дел од нив, оваа верзиjа се соочува со проблемот на закочување од страна на првото барање во редицата (Head of Line Blocking, англ.), односно доколку на серверот му е потребно долго време да го опслужи тековното барање во редот W на пристигнати барања, останатите барања не можат да бидат опслужени, што може да резултира со долго време на чекање за прикажување на комплетната веб страна каj клиентот. Овие проблеми се надминуваат со верзиjата HTTP/2.0, коjа се поjавува во 2015 година. Оваа верзиjа овозможува: мултиплексирање на повеќе барања преку една TCP конекциjа; приоретизирање на барања, опслужуваjќи ги оние кои се со поголема важ- ност за првично прикажување на елементи на веб страницата, со цел постиг- нување подобро корисничко искуство; 14 Основи на веб програмирање со користење на Spring рамката понапредна компресиjа на заглавиjа; и можност серверот самостоjно да иницира комуникациjа со клиентот (push notifications, англ.). HTTP/2.0 jа поддржуваат познатите веб прелистувачи и веб сервери, па затоа денес, наjголемиот дел од веб саjтовите jа користат токму оваа верзиjа за достава на содржини. Следната верзиjа на протоколот е HTTP/3.0, но таа сѐ уште е во изработка и не е широко прифатена. Се разликува по тоа што наместо TCP, како транспортен протокол го користи експерименталниот протокол QUIC2 , имплементиран над UDP. ss 1.5 HTTP методи re HTTP методите се користат за да jа означат намерата на барањето кое даден клиент го испраќа до серверот, како и да прецизираат што всушност очекува og клиентот како успешен одговор од тоа барање. Главните методи кои се користат во рамки на HTTP протоколот се GET и POST. Останатите методи дефинирани во протоколот се HEAD, PUT, DELETE, CONNECT, OPTIONS и TRACE. pr Преглед на HTTP методите е даден на Табела 1.1. HTTP GET методот се користи од страна на клиентот за да биде побарана тековната репрезентациjа на ресурсот на коj се однесува барањето. Доколку, на in пример, клиентот користи GET метод за своето барање и барањето се однесува за ресурсот https://finki.ukim.mk, тогаш серверот е должен како одговор на барањето да jа врати тековната содржина на овоj веб ресурс. Доколку по из- весно време се промени содржината на ресурсот (се ажурира веб страната, се k обjават нови информации, итн.), ново барање со истиот метод кон овоj ресурс ќе or резултира со нов, различен одговор од страна на серверот, затоа што согласно стандардот, одговорите на барањата кои го користат GET методот секогаш се W однесуваат за тековната репрезентациjа на ресурсот. Важно е да се напомене и дека GET е еден од двата задолжителни HTTP методи (заедно со HEAD), кои согласно стандардот, мора да бидат поддржани од секоj HTTP сервер. Главната цел на методот GET е да го наведе ресурсот (датотека или сервис) преку неговата URL адреса во почетната линиjа на барањето, а како одговор од серверот да го добие бараниот ресурс. Сепак, постои можност да се пренесат и кориснички дефинирани податоци до серверот, но нивната количината е огра- ничена, бидеjќи единствениот начин да се пренесат е да бидат вклучени како дел од URI адресата на ресурсот. Примери за пренос на податоци во оваа форма 2 QUIC https://datatracker.ietf.org/doc/html/rfc8999 15 Основи на веб програмирање со користење на Spring рамката Метод Опис GET Се бара тековната репрезентациjа на ресурсот. Во овие барања не се испраќа содржина во телото. HEAD Исто како GET, но без пренос на содржината во телото на одго- ворот коj се враќа т.е. одговорот нема тело. POST Се бара обработка на содржината испратена во телото на бара- њето. PUT Се бара да се замени тековната репрезентациjа на ресурсот со содржината испратена во телото на барањето. DELETE Се бара бришење на сите тековни репрезентации на ресурсот. CONNECT Се бара креирање на мрежен тунел до серверот означен со иден- ss тификаторот на ресурсот. OPTIONS Се бара опис на комуникациските можности на ресурсот. re TRACE Се изведува тест со праќање на пораките до ресурсот и нивно враќање назад до испраќачот, со цел да се одреди патеката по og коjа патуваат податоците. Табела 1.1: Опис на HTTP методите. Секое барање покраj метод содржи и ресурс коj се бара од серверот. pr се: пренос на броjот на страница коjа jа избрал корисникот од листа на про- дукти поделена во страници со фиксна големина, текст од пребарување за коj in серверот треба да даде резултат, итн. Потребно е да се внимава да не се пренесу- ваат сензитивни податоци (лозинки, броеви на платежни картички, итн.) преку GET методот, бидеjќи дури и да се користи заштитена комуникациjа (HTTPS), k веб серверите водат дневник на обработени барања во кои jа запишуваат првата or линиjа од барањето, па на тоj начин веб администраторот има увид во сите по- датоци кои се пренеле преку URL адресата. Овоj метод наjчесто се користи при W внесување на URL адреса во прелистувачот и при клик на линкови. HTTP POST методот се користи од страна на клиентот за да биде испратена содржина до серверот, за коjа се бара да биде обработена од страна на самиот сервер. Притоа, обработката зависи од ресурсот кон коj е испратено ова барање. На пример, некои од наjчестите употреби на POST барањата се: испраќање блок на податоци (пр. податоци внесени во HTML форма) до процес коj треба да ги обработи, испраќање текстуална содржина, коментар, слика или видео содржина на социjална мрежа или блог, со цел неjзино обjавување, додавање податоци на веќе постоечка репрезентациjа на ресурс, итн. 16 Основи на веб програмирање со користење на Spring рамката 1.6 HTTP статусни кодови Статусните кодови претставуваат троцифрени цели броеви кои го обjаснуваат резултатот од барањето и значењето на одговорот, односно означуваат дали бара- њето било успешно и што претставува одговорот (доколку воопшто е испратен). Валидни статусни кодови се кодовите од 100 – 599. Првата цифра од статусниот код jа означува класата на одговорот. Втората и третата цифра се користат за да се прецизира резултатот од барањето. Првата цифра може да има една од пет вредности, дефинирани како посебни класи и прикажани во Табела 1.2. Код Категориjа Опис ss 1xx Информативен статус Барањето е примено, процесот продолжува. 2xx Успешно барање Барањето е успешно примено, разбрано е и е re обработено. 3xx Пренасочување Потребно е да се преземат дополнителни актив- 4xx Клиентска грешка og ности за да се комплетира барањето. Барањето содржи погрешна синтакса или не мо- же да биде исполнето. pr 5xx Серверска грешка Серверот не успеа да го обработи валидното ба- рање. Табела 1.2: Опис на HTTP статусните кодови. Секоj одговор од серверот содржи in точно еден статусен код. Едно барање од клиентот наjчесто добива еден одговор од серверот коj има k точно еден статусен код. Но, согласно стандардот, едно барање од клиентот може or да добие и повеќе привремени одговори со статусни кодови од категориjата „ин- формативно“ (1xx), после кои ќе следи точно еден финален одговор со статусен W код од една од останатите категории. Во продолжение ќе разгледаме некои од наjчестите статусни кодови со кои се среќаваме при користење на HTTP протоколот, но и при програмирање на веб апликации: Статусен код 200 со статусен опис OK е наjчестиот стандарден одговор коj се добива од веб серверите. Означува дека барањето за ресурсот е успешно и дека бараниот ресурс е во телото на одговорот. Статусен код 301 со статусен опис Moved Permanently се добива кога корисникот бара ресурс од серверот коj е перманентно преместен на друга 17 Основи на веб програмирање со користење на Spring рамката локациjа. На пример, ако го смениме доменот на веб саjтот, со тоа jа ме- нуваме и локациjата на саjтот. За да може корисниците кои се упатуваат до старата URL адреса да пристигнат до ресурсот на новата URL адреса, веб администраторот на саjтот со старото име поставува правило со кое сите барања до него да бидат пренасочени кон новиот веб саjт, па затоа секое барање со стара адреса резултира со враќање на статусен код 301 и информациjа за тоа коjа е новата адреса на коjа треба да се обрати пре- листувачот. По добивање на одговор со ваков статусен код, прелистувачот генерира ново барање кон новата локациjа. Статусен код 400 со статусен опис Bad Request означува дека клиен- тот испраќа податоци до серверот во погрешен формат коj е неприфатлив за серверот. На пример, ако корисникот испраќа текстуална вредност за ss сервис коj очекува целоброjна вредност, сервисот не може да го обработи барањето и го одбива како несоодветно. re Статусен код 403 со статусен опис Forbidden се добива кога корисникот се обидува да пристапи до ресурс за коj нема дозвола. На пример, ако не- og автентициран корисник на веб саjт се обиде да пристапи до ресурси за ад- министрациjа на саjтот кои се достапни само за администраторот, серверот одговара со забрана за пристап поради немање дозвола. pr Статусен код 404 со статусен опис Not Found се враќа доколку ресурсот што го бараме не постои на серверот. На пример, ако се згреши името на ресурсот и ако ресурс со такво име не постои на серверот, тогаш тоj ни in враќа одговор со статус 404. Статусен код 500 со статусен опис Internal Server Error се враќа кога настанува грешка на серверска страна. Пример за порака со ваков статус е барање за ресурс придружно со податоци кои се во валиден формат, но k поради лошо дизаjниран софтвер, обработката на барањето предизвикало or грешка со коjа веб апликациjата не успеала да се справи. Одговори со ваков статусен код значат пропуст во апликациjата, па затоа не е пожелно да е W поjави во продукциска верзиjа на веб апликациjа. Причините за грешките во ваквите случаи треба да се бараат во логовите на веб апликациjата, кои во одредени случаи може и да бидат вклучени во телото на одговорот. 1.7 Полиња на HTTP заглавjе Полињата на заглавието на HTTP барањето и одговорот носат дополнителни по- датоци со информации за нив и им служат на серверот и клиентот при обработка на пристигнатата порака. Важноста на овие полиња од аспект на веб програми- рање е во тоа што, понекогаш, на серверска страна е потребно експлицитно да 18 Основи на веб програмирање со користење на Spring рамката се прочитаат нивните вредности за да се знае како да се обработат податоците во барањето, или пак да се постави нивната вредност, со цел да му се назначи на прелистувачот како да ги обработува податоците кои пристигнуваат. Листата на заглавиjата е прилично долга, но оние кои се од поголема важност за целите на книгата се опишани во додаток А. 1.8 Колачиња HTTP по природа е безсостоjбен протокол, што значи дека откако серверот ќе добие барање од клиент и откако ќе го опслужи, ги ослободува сите ресурси кои биле резервирани за негова обработка. Серверот не води никаква евиденци- ss jа за претходната комуникациjа со клие?

Document Details

Related

Full Transcript

Upgrade to continue