Відповіді на запитання по веб технологіям

HTTPS- протокол безпечної передачі, підтримує технологію шифрування TLS/SSL.
Докладніше як працює HTTPS можеш почитати в статті.

• 1xx (Informational) - ці відповіді передають інформацію про процес передачі. Клієнт повинен мати можливість прийняти їх, але відповідати на них не потрібно.
• 2xx (Success) - ці коди інформують про успішне прийняття та обробку запиту від клієнта. Залежно від методу, відповіді з цими статусами можуть містити тіло відповіді з даними від сервера.
• 3xx (Redirection) - коди цього класу повідомляють клієнту, що для успішного виконання операції необхідно зробити інший запит, як правило, по іншому URI.
• 4xx (Client Error) - ці коди вказують на помилку з боку клієнта. Наприклад, якщо у запиті міститься синтаксична помилка (400) або ми посилаємося на неіснуючий ресурс (404)
• 5xx (Server Error) - служать для відображення помилок на сервері

HyperText Transfer Protocol це протокол для клієнт-серверної взаємодії. З його допомогою клієнт може робити запити до сервера і отримувати інформацію або вносити зміни в дані на сервері.

Протокол WebSocket забезпечує можливість обміну даними між браузером і сервером через постійне з'єднання. Дані передаються в обох напрямках у вигляді “пакетів”, без розриву з'єднання і додаткових HTTP-запитів.

WebSocket добре підходить для сервісів, які потребують постійного обміну даними, наприклад онлайн ігри, маркетплейси що працюють у реальному часі і т.д.

Cookie - дані які можуть передаватися між сервером і клієнтом у заголовках HTTP запитів. Максимальний розмір кукі становить 4 КБ. Часто використовується для передачі конфіденційної інформації, такої як токен авторизації та даних користувача. Куки мають термін життя. І можуть мати параметр HttpOnly, який забороняє доступ до цього cookie JS коду з метою безпеки.

Localstorage - це об'єкт, що знаходиться у window для зберігання даних у форматі ключ-значення. Дані в localstorage зберігаються у вигляді рядків, не мають терміну зберігання і можуть бути змінені або видалені користувачем. Localstorage часто застосовується для зберігання налаштувань користувача, наприклад, теми сайту або вибраних фільтрів пошуку, щоб при перезавантаженні сайту або відкритті його через якийсь час ці налаштування були такими, як вибрав користувач. Використання localstorage дозволяє не зберігати деякі дані в базі даних.

Sessionstorage - цей об'єкт дуже схожий на localstorage, але зберігає дані на час існування сесії сторінки. Сесія сторінки створюється при відкритті нової вкладки браузера і зберігається при перезавантаженні сторінки в цій вкладці. Якщо створити нову вкладку з однією адресою, то буде створена нова сесія.

API (Application Programming Interface) перекладається як Програмний Інтерфейс Програми - це частина серверної програми яка дозволяє отримувати запити та відповідати на них. Гарним прикладом є API для прогнозу погоди.
У компанії є сервер до бази даних якого вносяться дані про погоду. Різні клієнти, будь-то у девайси типу телефонів або інші сайти, можуть надсилати запити з даними типу місцезнаходження на цей сервер, і сервер повертатиме їм дані про погоду в даному регіоні. Також цей сервер може мати функції додавання погодних даних у БД та багато інших. Все це і є API, це спосіб спілкування із сервером. До сервера можуть звертатися як клієнтські додатки, так і інші сервери. На практиці ви найчастіше зустрічатиметеся з REST API та Websocket API. Докладніше про ці підходи можна прочитати в цьому розділі.

Усі пристрої підключені до мережі, для зв'язку один з одним використовують цифрові номери, які називаються IP-адресами. Наприклад, якщо ви введете в адресному рядку свого браузера таке значення - 216.58.215.99, то ви потрапите на сайт Google.
Але людині складно запам'ятовувати цифрові значення, набагато простіше запам'ятовувати буквені. Цими буквеними значеннями є домени.
Але як нашому браузеру зрозуміти на яку айпі адресу слід перейти якщо ми ввели якісь букви в адресному рядку? Для цього і існує DNS (Domain Name System).

Сервери DNS перетворять запити щодо доменів на IP-адреси, забезпечуючи з'єднання користувача з певним сервером при введенні доменного імені в браузер.
Спрощена схема роботи DNS виглядає так:

1. Користувач вводить домен у браузері
2. Запит через провайдера потрапляє до DNS сервера
3. DNS сервер шукає відповідну домену IP-адресу і відправляє його назад браузеру
4. Браузер звертається до сервера потрібного сайту використовуючи IP-адресу
5. Сервер із цією адресою відповідає браузеру відправляючи йому сторінку та браузер відображає її користувачеві

Розглянемо приклад. Ваша міжнародна компанія знаходиться в США і її сервери знаходяться там же, а ваші клієнти живуть по всьому світу. Якщо клієнт з Австралії вирішить зайти на ваш сервіс, йому доведеться завантажувати код та медіафайли із серверів у США. Враховуючи, що сумарний пакет даних може важити мегабайти, клієнт чекатиме кілька секунд. А статистика нам каже, що клієнти не хочуть користуватися сервісом, у якого завантаження сторінки перевищує 4 секунди. Для того, щоб клієнтам не доводилося завантажувати дані через весь світ і існує CDN (Content Delivery Network). Принцип роботи CDN полягає в тому, що сервіси, що надають цю можливість, мають сервери, що кешують, по всьому світу, які дублюють оригінальні дані. Тобто користувача з Австраллі перенаправить на найближчий сервер, який, швидше за все, знаходиться в Австралії, і завантаження сторінки у нього буде набагато швидше.
Використання CDN також має інші переваги:

• якщо ваш головний сервер впав, то користувачі матимуть доступ до контенту, який продубльований на серверах, що кеширують його, по всьому світу
• використання CDN знижує навантаження на головний сервер
  Лідерами у наданні CDN є Akamai та Cloudflare. Також великі хостинги, такі як AWS і Azure, надають такі ж можливості.

IP (Internet Protocol) адреса - це унікальна цифрова адреса пристрою підключеного до мережі Інтернет. Сьогодні є дві версії адрес IPv4 і IPv6. IPv4 - 4 числа від 0 до 255 192.168.5.1

IPv6 - 8 чисел від 0 до 255 192.168.50.175.190.168.7.1
IP адреса дозволяє знайти необхідний пристрій в мережі для обміну інформацією.

PWA - це підхід для створення зручних сайтів, які можна зберігати як програму на телефоні. Для реалізації PWA використовуються такі технології:

• Service Worker - це проксируючий шар у браузері між фронтом і беком, за допомогою нього ми зможемо отримати доступ до Storage та IndexDB.
• Application Shell - це скелет розмітки сайту без контенту, який буде зберігатися на пристрої користувача. Це дозволить відразу показати красивий інтерфейс з прелоудерами поки буде вантажиться контент, це дає ефект нативного застосування.
• Web App Manifest - цей JSON файл дозволяє встановити PWA як окремий додаток.
• Push Notifications - PWA сайти повинні вміти працювати з нотифікешенами.

REST (Representational State Transfer) що можна перекласти як "передача репрезентативного стану" - це архітектурний шаблон для створення веб-сервісів.
REST визначає всього 5 принципів:

• клієнт-серверна модель - Це вимога ділить веб-сервіс на дві частини, сервер та клієнта. Сервер це програма, яка зберігає та обробляє дані. Клієнт це програма, яка обробляє взаємодії з користувачем і обмінюється даними з сервером за допомогою API. Цей поділ дозволяє покращувати ці частини окремо.
• відсутність стану - Сервери не зберігають інформацію про стан клієнта та про минулі взаємодії з ним. Уся необхідна інформація для обробки запиту від клієнта до сервера повинна бути у запиті. Це знижує навантаження на сервер, тому що, якщо до сервера підключено безліч клієнтів, серверу не потрібно зберігати всі дані про їх минулі взаємодії, а потрібно просто обробити один запит від певного клієнта.
• кешування - Клієнти часто запитують у сервера ті самі дані. Для того, щоб знизити навантаження на сервер, клієнт може зберігати ці дані у себе або вони можуть зберігатися на проміжних серверах.
• єдиний інтерфейс - Доступ до всіх даних у сервісі повинен здійснюватися однаково. Наприклад, якщо ви додаєте функціональність по роботі з квитанціями користувача, то ця нова функціональність не повинна відрізнятися від старої функціональності роботи з рахунками користувачів. Логіка звернення до сервера для обробки будь-яких запитів має бути однаковою, а також використовувати однакові формати даних.
• багаторівнева система - До цього ми розглядали сервер як єдину сутність. Але це може бути система програм, що включає: кілька серверів і проміжні проксі-сервера для розподілу навантаження між серверами, кешування даних, забезпечення безпеки і т.д. Всі ці елементи системи ізольовані і не знають структуру всієї системи, знають тільки про сусідів з якими спілкуються. Це дозволяє легко розширювати систему, додаючи до неї незалежні частини.
  
  Якщо ваш веб-сервіс застосовує всі ці принципи, це RESTful сервіс. Якщо ви використовуєте частину з них, його можна назвати RESTlike

Server Side Rendering - це методика рендерингу односторінкового клієнтського додатку (SPA) на сервері і подальшого відправлення на клієнт готової сторінки. Це дозволяє використовувати динамічні компоненти як статичну розмітку HTML.

Такий підхід може бути корисним для пошукової оптимізації (SEO), коли при індексації сторінки JS код не відтворюється кроулером і сторінка, що індексується, не містить необхідної інформації або викидає помилки.

SSR також може бути корисним у ситуаціях, коли завантаження великого блоку JS коду утруднена через повільну швидкість мережі, в цьому випадку ми можемо відрендерити початковий екран на сервері, відправити його в готовому вигляді клієнту, і після цього відправити інший код. У такому випадку користувач відразу отримає працюючу програму з контентом і не чекатиме повного завантаження великої програми.

HTTP запит складається з:

1. Стартовий рядок (Starting line) - визначає суть запиту
2. Заголовки (Headers) - містить параметри передачі
3. Тіло запиту (Body) - безпосередньо дані запиту

Стартовий рядок має наступний формат Метод URI HTTP/Версія

де:

• Метод - тип запиту, одне слово великими літерами, типу GET або POST. Усі методи описані в окремому питанні у цьому розділі.
• URI - шлях до запитуваного документа
• Версія - пара розділених точкою цифр. Наприклад: 1.0

Заголовки (опціонально) - це рядки, що містять розділену двокрапкою пару ключ-значення. Заголовки описують тіло запиту, параметри передачі запиту та іншу додаткову інформацію. Приклад заголовка:

Server: Apache/2.2.11 (Win32) PHP/5.3.0

Last-Modified: Sat, 16 Jan 2010 21:16:42 GMT

Content-Type: text/plain; charset=windows-1251

Content-Language: uk

Тіло запиту - містить відправлену інформацію. Може використовуватись у деяких запитах, таких як POST

GET - використовується для запиту даних із сервера. Також за допомогою цього запиту можна запускати якісь процеси на сервері.
Для передачі даних GET запиту можна додати параметри в URI після символу ?
Наприклад: GET /path/resource?param1=value1&param2=value2* HTTP/1.1*
Але все ж таки краще використовувати цей метод саме для отримання даних, а для відправки використовувати POST

HEAD - запитує заголовки ідентичні тим, що повертаються, якщо вказаний ресурс буде запрошений за допомогою методу GET.
Відповідь на метод HEAD не повинен містити тіло.
Його можна застосовувати для перевірки наявності даних за вказаним URI або перевіряти, чи не змінювалися дані з моменту останнього звернення

POST - використовується для передачі інформації користувача на сервер, наприклад дані форм або завантажувані користувачем файли. Дані передаються у body запиту

PUT - застосовується для завантаження даних на вказаний у запиті URI. Різниця між POST і PUT полягає в тому, що використання POST передбачає обробку переданих даних на сервері, а PUT передбачає що передані дані відповідають тому типу даних які зберігаються за вказаним URI
PATCH - схожий на PUT, тільки застосовується для часткової зміни зазначених даних
DELETE - для видалення зазначених даних

OPTIONS - використовується для перевірки можливостей сервера та параметрів з'єднання. Наприклад з допомогою цього можна дізнатися які методи запитів підтримує сервер.
Також використовується для перевірки працездатності сервера.
TRACE - повертає отриманий запит так, що клієнт може побачити, яку інформацію проміжні сервери додають або змінюють у запиті

CONNECT - перетворює з'єднання запиту в прозорий TCP/IP-тунель, зазвичай щоб встановити захищене SSL-з'єднання

Куки - це невеликі (не більше 4096 байт) рядки з даними, які зберігаються в браузері. Куки передаються в заголовках HTTP запиту і використовуються для зберігання даних, які повинні бути одночасно на сервері та на клієнті, наприклад, токенів авторизації та даних користувача.
Куки зазвичай встановлюються сервером і передаються браузеру, браузер автоматично додаватиме їх у запити, що надсилаються на сервер.

Один з найчастіших випадків використання cookie – це аутентифікація:

1. При вході на сайт сервер надсилає у відповідь HTTP-заголовок Set-Cookie для того, щоб встановити cookie.
2. Під час наступного запиту до цього домену браузер посилає на сервер HTTP-заголовок Cookie.
3. Таким чином сервер розуміє, хто зробив запит.

CORSи механізм дозволяє додатку клієнта отримувати дані з різних доменів. З метою безпеки, браузер забороняє робити запити, що ініціюються скриптами до інших джерел крім домену з якого була завантажена сторінка.

Наприклад, ваш додаток знаходиться на домені site.com, і частина контенту для цієї програми на content.com. Ви не зможете просто так взяти і завантажити контент на сайт передавши запит на content.com, наприклад, за допомогою Fetch API.

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