HTTP: Протокол, який повинен розуміти кожний веб-розробник (Частина 1)

Ukrainian (українська мова) translation by Nadia Gonzales (you can also view the original English article)

HTTP означає Hypertext Transfer Protocol (* протокол прикладного рівня для "переговорів" про доставлення Web-сервером документа Web-браузеру. НТТР служить також для передачі XML-файлів, VoiceXML, WML, потокового відео та аудіо. Звичайно використовує порт 80, а у якості протоколу транспортного рівня - TCP. Головний протокол WWW, визначений у RFC 1945 (НТТР 1.0), 2068 и 2616 (НТТР 1.1), за допомогою якого HTML-документи пересилаються по мережі від вузла до вузла. НТТР підтримує постійні (передача багатьох об'єктів) та непостійні з'єднання (передача одного об'єкта веб-документа за сеанс обміну між клієнтом та сервером), а також два методи ідентифікації користувачів: авторизацію та об'єкти (файли) cookie. Тут і надалі примітка перекладача). Це протокол рівня застосувань без запам'ятовування стану (* stateless; не передбачає зберігання інформації про сесію користувача; кожна передача даних вважається новою сесією) для спілкування розподілених інформаційних систем; також є основою сучасної Всесвітньої павутини. Якщо ви – веб-розробник, то повинні мати ясне уявлення про цей протокол.

Давайте розглянемо цей потужний протокол через призму веб-розробника. Ми розглянемо цю тему в двох частинах посібника. У першій ми розглянемо основи та дамо загальне уявлення про заголовки запиту та відповіді. У наступній частині ми розглянемо спеціальні питання технології HTTP, а саме: гешування, реалізацію з'єднання та автентифікацію (* у системі комп'ютерної безпеки – процес, що дозволяє встановити, що користувач або комп'ютер (сервер), що намагається отримати інтерактивний доступ до певної категорії інформації, комп'ютерної системи, електронної пошти, дійсно той, за кого себе видає).

Хоча я згадаю деякі деталі відносно заголовків, за вичерпним описом вам краще буде звернутися до RFC (RFC 2616). Я буду посилатися на певні частини документа RFC протягом статті.

Основи HTTP

HTTP дозволяє спілкуватися системам з різною архітектурою та конфігурацією мережі (* певний склад обладнання ЛОМ (локальна обчислювальна мережа), схему його з'єднання та ПЗ мережі).

Це можливо завдяки тому, що цей протокол пред'являє базові вимоги до систем і не зберігає стан між обмінами різними повідомленнями.

Через це протокол HTTP вважається протоколом без запам'ятовування стану. Для транспортування повідомлень звичайно використовується протокол TCP (* Transmission Control Protocol; протокол керування передаванням; широко використовуваний в Інтернеті мережний протокол транспортного рівня з набору TCP/IP. Гарантує доставку переданих пакетів даних у потрібній послідовності, але трафік у цьому разі може бути дуже нерівномірний, тому що пакети зазнають усіляких затримок), проте може використовуватися будь-який інший придатний для транспортування повідомлень механізм (* наприклад, QUIC (Quick UDP Internet Connections) – експериментальний інтернет-протокол, розроблений Google в кінці 2012 року). Порт за налаштуванням для HTTP – 80, але можуть використовуватися й інші порти.

Також можна додавати та відправляти спеціалізовані (* пов'язані з (конкретним) застосуванням, на відміну від стандартизованих у RFC заголовків) власні заголовки до сервера (* і від сервера).

Обмін повідомленнями між клієнтом та сервером відбувається за схемою «запит–відповідь». Клієнт починає спілкування, відправляючи повідомлення запиту HTTP, у відповідь на яке сервер відсилає повідомлення відповіді HTTP. Ми розглянемо цю основоположну пару у наступному розділі.

Поточна версія протоколу – HTTP/1.1, у якій додано додаткові можливості у порівнянні з попередньою – HTTP/1.0. Серед них, на мій погляд, найважливішими є: тривалі з'єднання (* persistent connections; передавання в одному TCP-з'єднанні декількох об'єктів), кодування передавання даних типу "chunked" (* частинами) (* chunked transfer-coding; механізм передавання даних у протоколі передавання гіпертексту (HTTP), що дозволяє надійно доставляти дані від сервера клієнту без необхідності знати точний розмір усього тіла HTTP-повідомлення заздалегідь. Це досягається розбиванням повідомлення на невеликі частини (chunks), а потім передаванням кожної частини з зазначенням тільки її розміру. Завершення передавання повідомлення визначається наявністю останньої частини з нульовою довжиною. Такий механізм дозволяє передати динамічно сформовані об'єкти, для котрих не можливо визначити розмір заздалегідь. Він з'явився у версії HTTP/1.1. Без механізму сhunked transfer encoding з кожним HTTP-пакетом необхідно вказувати заголовок Content-Length, щоб клієнт міг знайти кінець повідомлення, яке передається) і тонко гранульовані (* метафоричне визначення (позначення) процесу чи системи для роботи з невеликими об'єктами, наприклад, окремими бітами та байтами, а не з відносно великими об'єктами, наприклад, файлами чи записами) заголовки, за допомогою яких задаються директиви для механізму гешування. Ми коротко розглянемо ці можливості у цій частині; детальний розгляд буде у другій.

URL-адреси

В основі комунікації по Всесвітній павутині лежать повідомлення запитів, які пересилаються за допомогою URL-адрес (* Uniform Resource Locator – уніфікований покажчик [місцезнаходження інформаційного] ресурсу). Впевнений, що ви вже знайомі з ними, однак для повноти картини ми їх коротко розглянемо. За своєю структурою URL-адреси прості; у ній виділяють наступні компоненти:

Звичайно використовується протокол HTTP, проте їм також може бути і HTTPS (* HTTP Secure; протокол захищеного передавання гіпертексту. Розширення протоколу НТТР; сумісний із НТТР, проте використовує порт 443 протоколу TCP) для забезпечення зв'язку по захищеному каналу. Порт за налаштуванням – 80, проте його можна явно задати, як показано вище. Шлях до об'єкта – це локальний шлях до ресурсу на сервері.

Методи

Також у їх розпорядженні є проксі для налагодження веб-застосунків, наприклад, Fiddler (* працює з трафіком між вашим комп'ютером та віддаленим сервером і дозволяє переглядати та змінювати його) (для Windows) та Charles Proxy (для OSX).

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

Ці методи запиту перелічено нижче:

GET: для запиту ресурсу. В URL-адресі міститься вся необхідна інформація для визначення місцезнаходження та повернення ресурсу сервером.
POST: для створення нового ресурсу. Запити POST звичайно містять дані для створення нового ресурсу.
PUT: для оновлення існуючого ресурсу. У вмісті можуть знаходитися оновлені дані для ресурсу.
DELETE: для видалення існуючого ресурсу.

Вище зазначені методи найбільш поширені, і більшість інструментів та фреймворків надають функції для роботи з цими методами. Іноді PUT і DELETE розглядаються як спеціалізовані версії методу POST і можуть бути оформлені у вигляді запитів POST із даними, що визначають точну дію: створити, оновити, видалити.

Також в HTTP є підтримка деяких рідше використовуваних методів:

HEAD: подібний до GET, проте не передається тіло повідомлення. Він використовується для отримання заголовків певного ресурсу від сервера, звичайно для того, щоб перевірити за допомогою тимчасової позначки, чи не змінився ресурс.
TRACE: використовується для отримання від сервера інформації про "стрибки" (* найближчий маршрутизатор, маршрутизатор, що знаходиться на відстані одного "стрибка"), через які пройшов запит. Кожний проміжний проксі-сервер (* програма кешування відповідей на запити клієнтських частин застосувань, які посилають в Інтернет або в WWW, що працює на прикладному рівні. Копії отриманих веб-сторінок, файли тощо зберігають якийсь час на сервері, і після одержання наступних аналогічних запитів ргоху-сервер сам висилає наявні копії, щоб скоротити час відгуку й обсяг мережного трафіку. Крім того, ргоху-сервер може фільтрувати запити, закриваючи доступ до сайтів певного типу. Структурно ргоху-сервер складено з великої кількості специфічних посередників для конкретних застосувань: посередника для веб-сторінок, для ftp, для електронної пошти, для RealAudio тощо) або шлюз (* мережний пристрій або комп'ютер, який здійснює зв'язок між двома різними (що використовують різні протоколи комунікації) комп'ютерними мережами або мейнфреймом і мережею. Крім передавання даних можуть виконувати фільтрацію) при цьому будуть заносити свою IP-адресу (* використовується для ідентифікації вузла в мережі та для визначення інформації маршрутизації) або ім'я DNS (* механізм, використовуваний у мережі, що встановлює відповідність між числовими IP-адресами та текстовими іменами) до поля Via заголовка. Його можна використовувати для діагностики.
OPTIONS: для отримання підтримуваних сервером можливостей. На стороні клієнта його можна використовувати для зміни запиту в залежності від можливостей, підтримуваних сервером.

Коди стану (* значення, що повертається процедурою або функцією та показує стан пристрою або процесу).

Маючи URL-адреси та методи, клієнт може ініціювати запити до сервера. У відповідь сервер відправляє відповіді з кодами стану та вмістом повідомлень. Код стану – важливий компонент повідомлення; він вказує клієнту, як інтерпретувати відповідь сервера. У специфікації (* документ, що описує вимоги, яким мають відповідати продукт або послуга; детальний опис функцій будь-чого (наприклад, програми, стандарту)) HTTP встановлюються певні діапазони чисел для конкретних типів відповідей:

1xx: Інформація про процес передачі

Усім клієнтам HTTP/1.1 необхідно, щоб у повідомленні був заголовок Transfer-Encoding.

Цей клас кодів з'явився в HTTP/1.1 та використовується просто для попереднього спілкування клієнта та сервера. Сервер може відіслати у відповідь на повідомлення клієнта з заголовком Expect: 100-continue відповідь (* наприклад, 100 Continue (Продовжувати) (код та відповідна пояснююча фраза)), інструктуючи клієнта продовжувати відправлення частини запиту, що залишилась, або проігнорувати повідомлення, якщо той вже її відіслав. При використанні HTTP/1.0 повідомлення з такими кодами повинні ігноруватися (* у версії 1.1 клієнт повинен бути готовий пройняти цей клас повідомлень як звичайну відповідь, але серверу нічого відправляти не потрібно).

2xx: Інформація про вдалий прийом та оброблення запиту клієнта

Коди цього класу повідомляють клієнтові, що його запит вдало оброблено. Найчастіше зустрічається код (* та відповідна фраза) 200 OK. На запити за методом GET сервер відправляє у відповідь запитувані дані в тілі повідомлення. Нижче наведено деякі рідше використовувані коди (* та відповідні фрази):

202 Accepted (* Прийнято): запит було прийнято на оброблення (* але його не завершено), але у відповіді може не бути запитуваних даних. Цей варіант корисний для асинхронної обробки на стороні сервера. Сервер може вирішити відправити інформацію для моніторингу (* безперервний у часі чи періодичний процес сканування стану яких-небудь ресурсів (наприклад, інформаційних) з ціллю збору даних, контролю, керування та/або змістовного аналізу).
204 No Content (* Нема вмісту): тіло повідомлення не передається.
205 Reset Content (* Скинути вміст): клієнт повинен скинути (* повернути вихідні значення) уведені користувачем дані (* тіла повідомлення сервер при цьому не передає і документ оновлювати не обов'язково).
206 Partial Content (* Частковий вміст): вказує, що у відповіді міститься тільки частина ресурсу. Клієнт може надсилати додаткові заголовки, за допомогою яких вказується точний діапазон запитуваного ресурсу та інформація про термін дії контенту.

3xx: Переадресація

404 повідомляє, що запитуваний ресурс не існує на сервері.

Цей код вказує клієнту, що необхідно буде виконати додаткову дію. Найпоширеніший варіант – виконання запиту за іншою URL-адресою (* вказаною у додатковому заголовку Location) для отримання запитуваного ресурсу.

301 Moved Permanently (* Постійно переміщений): запитуваний об'єкт було остаточно перенесено на новий URL.
303 See Other (* Дивитися інший): запитуваний об'єкт було тимчасово перенесено на нову URL-адресу. Тимчасовий URL вказується у заголовку Location відповіді.
304 Not Modified (* Не модифікований): сервер виявив, що ресурс не було змінено і клієнту варто використовувати копію з кеш-пам'яті. Це реалізується за допомогою того, що клієнт відправляє певне значення (хеш-значення вмісту) у заголовку ETag (Entity Tag). Сервер порівнює це значення зі своїм власним токеном (* засіб ідентифікації) для запитуваного ресурсу на наявність змін.

4xx: Інформація про помилки з боку клієнта

Ці коди використовуються, коли сервер вважає, що клієнт зробив помилку: чи то помилковий запит, чи то запит недоступного для клієнта ресурсу. Найбільш популярне повідомлення у цьому випадку – 404 Not Found (* Не знайдено), значення якого, гадаю, всім відомо. 404 повідомляє, що запитуваний ресурс не існує на сервері. Деякі з решти кодів (* і відповідних фраз) цього класу наведено нижче:

400 Bad Request ( Зіпсований запит): у запиті знайдено помилку.
401 Unauthorized (* Несанкціонований доступ): для здійснення запиту необхідна автентифікація. Клієнт може повторно виконати запит, додавши заголовок Authorization. Якщо клієнт вже використовував цей заголовок, то це означає, що було вказано помилкові для вдалої автентифікації дані.
403 Forbidden (* Заборонено): сервер відмовив клієнту у доступі до вказаного ресурсу.
405 Method Not Allowed (* Метод не допустимий): у рядку запиту використовувався неприпустимий метод HTTP або ж сервер не підтримує цей метод.
409 Conflict (* Конфлікт): сервер не зміг виконати запит, оскільки клієнт спробував змінити ресурс, відмітка часу якого не співпадає з такою клієнта. У більшості випадків конфліктна ситуація виникає при сумісному редагуванні ресурсу за допомогою запитів за методом PUT.

5xx: Інформація про помилки з боку сервера

Цей тип кодів використовується для повідомлення про невдале виконання операції через помилку з боку сервера. Найчастіше зустрічається код про помилку (* та відповідна фраза) 500 Internal Server Error (* Внутрішня помилка сервера; будь-яка помилка сервера, що не належить до інших помилок класу). До деяких інших кодів (* та відповідних фраз) цього класу належать:

501 Not Implemented (* Не реалізовано): сервер на цей момент не підтримує можливостей, необхідних для оброблення запиту.
503 Service Unavailable (* Сервіс недоступний): сервер не має можливості оброблювати запити з технічних причин або перевантажений. Звичайно сервер навіть не буде відповідати, і запит перевищить ліміт часу очікування від сервера (* timeout; час чекання події (зазвичай задають для операцій з периферійними пристроями), з настанням якої виникає й обробляється, наприклад, помилкова ситуація).

Формат HTTP-повідомлень

На цей час ми з'ясували, що URL-адреса, методи та коди стану – це фундаментальні компоненти пари HTTP запит/відповідь.

Тепер давайте розглянемо вміст цих повідомлень. У специфікації HTTP визначається наступна загальна структура повідомлень запиту та відповіді:

message = <start-line>
          *(<message-header>)
          CRLF
          [<message-body>]

<start-line> = Request-Line | Status-Line 
<message-header> = Field-Name ':' Field-Value

Розміщення пустого рядка між заголовками та тілом повідомлення є обов'язковим. У повідомленні може міститися один або декілька заголовків, серед котрих умовно (* згідно з контекстом) можна виділити:

загальні заголовки (general headers; застосовні для повідомлень і запиту, і відповіді).
заголовки запиту.
заголовки відповіді.
заголовки тіла об'єкта (entity headers).

У тілі повідомлення можуть міститися всі дані повідомлення або воно може бути поділено на частини, якщо використовується кодування передачі типу «chunked» (Transfer-Encoding: chunked). Усім клієнтам HTTP/1.1 необхідно, щоб у повідомленні був заголовок Transfer-Encoding.

Загальні заголовки

Є декілька заголовків, що використовуються і в повідомленнях запиту, і в повідомленнях відповіді:

general-header = Cache-Control            
               | Connection        
               | Date              
               | Pragma            
               | Trailer           
               | Transfer-Encoding 
               | Upgrade           
               | Via               
               | Warning

Ми вже знайомі з деякими з цих заголовків (Via і Transfer-Encoding). Ми розглянемо Cache-Control і Connection у другій частині.

Код стану – важливий компонент повідомлення; він вказує клієнту, як інтерпретувати відповідь сервера.

Заголовок Via використовується у повідомленнях, що передаються за методом TRACE, і оновлюється всіма проміжними проксі та шлюзами.
Заголовок Pragma вважається спеціалізованим заголовком і може бути використаний для додавання до повідомлення пов'язаних із конкретною реалізацією додатка заголовків. Найчастіше використовується директива Pragma: no-cache, що є еквівалентом Cache-Control: no-cache версії HTTP/1.1. Цей заголовок буде розглянуто у другій частині посібника.
Заголовок Date використовується для додавання часу створення повідомлення запиту/відповіді.
Upgrade використовується для переключення протоколів і дозволяє здійснювати плавний перехід на використання нового протоколу.
Transfer-Encoding звичайно використовується для поділення відповіді на менші частини за допомогою директиви Transfer-Encoding: chunked. Цей заголовок вперше з'явився у версії HTTP/1.1; дозволяє реалізувати потокову передачу даних відповіді клієнту (* переміщення даних частинами) (на відміну від пересилання копії даних повністю).

Заголовки тіла повідомлення

У повідомленнях запиту та відповіді можуть використовуватися заголовки для тіла об'єкта, щоб передати метаінформацію про вміст повідомлення (тіло повідомлення/об'єкта). До цього типу заголовків належать:

entity-header  = Allow                    
               | Content-Encoding  
               | Content-Language  
               | Content-Length    
               | Content-Location  
               | Content-MD5       
               | Content-Range     
               | Content-Type      
               | Expires           
               | Last-Modified

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

Завдяки заголовку Expires задається термін, по закінченні якого тіло повідомлення вважається застарілим. Цікаво, що при вказанні значення "never expires" цей термін дорівнює одному року. За допомогою заголовка Last-Modified вказується час останньої модифікації файлу.

Також можна додавати та відправляти спеціалізовані власні заголовки до сервера (* і від сервера); згідно з протоколом HTTP вони будуть розглядатися як заголовки об'єкта.

Ця можливість – механізм розширення полів заголовків (* дозволяє вводити додаткові поля заголовка об'єкта (entity-header fields), не змінюючи протокол, але ці поля можуть бути і не розпізнані отримувачем. Отримувач повинен ігнорувати нерозпізнані поля заголовка, а проксі-сервер повинен просто пересилати їх без змін), і в деяких реалізаціях додатків для комунікації можуть використовуватися саме ці спеціальні заголовки. Хоча HTTP підтримує спеціалізовані заголовки, у першу чергу його цікавлять заголовки відповіді і запиту, які ми й будемо розглядати далі.

Формат повідомлень запиту

Загальна структура повідомлень запиту така ж, як і вище, проте рядок запиту виглядає наступним чином:

Request-Line = Method SP URI SP HTTP-Version CRLF
Method = "OPTIONS"
       | "HEAD"  
       | "GET"  
       | "POST"  
       | "PUT"  
       | "DELETE"  
       | "TRACE"

SP – просторовий роздільник між лексемами. На місті HTTP-Version вказується "HTTP/1.1", і потім йде перехід на новий рядок. Таким чином, типове повідомлення запиту може виглядати наступним чином:

GET /articles/http-basics HTTP/1.1
Host: www.articles.com
Connection: keep-alive
Cache-Control: no-cache
Pragma: no-cache
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

Зверніть увагу на рядок запиту, за яким йде серія заголовків запиту. Заголовок Host є обов'язковим для клієнтів, що працюють за HTTP/1.1. Запити, виконувані за методом GET, не мають тіла об'єкта, а запити, виконувані за методом POST, можуть містити дані в тілі повідомлення для створення ресурсу.

Заголовки запиту грають роль модифікаторів повідомлення запиту. Повний список наявних заголовків запиту не дуже довгий, його наведено нижче: Заголовки, що не входять до списку, розглядаються як поля заголовка об'єкта.

request-header = Accept                   
               | Accept-Charset    
               | Accept-Encoding   
               | Accept-Language   
               | Authorization     
               | Expect            
               | From              
               | Host              
               | If-Match          
               | If-Modified-Since 
               | If-None-Match     
               | If-Range          
               | If-Unmodified-Since
               | Max-Forwards       
               | Proxy-Authorization
               | Range              
               | Referer            
               | TE                 
               | User-Agent

В заголовках з префіксом Accept вказуються допустимі для прийому клієнтом форми інформації, мова та набір символів. У From, Host, Referer і User-Agent вказуються деталі про клієнта, що відправив запит. Заголовки з префіксом If- використовуються для надання запиту гнучкості, і сервер надсилає відповідь тільки тоді, коли задана умова виконується. В іншому випадку надсилається відповідь 304 Not Modified. Умову може бути задано на основі мітки часу або ETag.

Формат повідомлень відповіді

Формат повідомлень відповіді схожий з таким повідомлень запиту, за винятком стартового рядка та заголовків. Стартовий рядок має наступну структуру:

1	Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF

На місті HTTP-Version вказується "HTTP/1.1".
Status-Code – один із раніше розглядуваних кодів стану.
Reason-Phrase – зрозуміла для людини версія (* пояснююча фраза) коду стану.

Типовий стартовий рядок відповіді про вдале виконання запиту може виглядати наступним чином:

1	HTTP/1.1 200 OK

Кількість заголовків відповіді також доволі обмежена; повний набір наведено нижче:

 response-header = Accept-Ranges
                 | Age
                 | ETag              
                 | Location          
                 | Proxy-Authenticate
                 | Retry-After       
                 | Server            
                 | Vary              
                 | WWW-Authenticate

У Age вказується час у секундах, коли повідомлення було згенеровано на сервері.
Значення ETag – хеш-значення об'єкта, отримане за допомогою алгоритму шифрування MD5 (* Message Digest 5); використовується для перевірки наявності змін ресурсу.
Location використовується для інструктування клієнта про переадресацію та містить нову URL-адресу.
У Server вказується сервер, що надіслав повідомлення.

Ми ознайомилися з великим об'ємом теорії на цей момент, так що не дивно, якщо ви задрімали. У наступних розділах у нас буде більше практики і ми попрацюємо з деякими інструментами, фреймворками та бібліотеками.

Інструменти для перегляду мережного трафіку за HTTP (* наприклад, потік повідомлень (даних) у локальній чи глобальній мережі. Завантаженість мережі (за аналогією з рухом автотранспорту по дорогах). Трафік складають передані дані і службова інформація, необхідна для організації їхнього проходження).

Розробникам доступно багато інструментів для моніторингу трафіка HTTP. Тут буде перелічено найбільш популярні.

Без сумнівів, фаворитом серед веб-розробників є інспектор Chrome/Webkit.

Також в їх розпорядженні є проксі для налагодження веб-застосунків, наприклад, Fiddler (* працює з трафіком між вашим комп'ютером та віддаленим сервером та дозволяє переглядати та змінювати його) (для Windows) та Charles Proxy (для OSX). Мій колега, Rey Bango, написав чудову статтю на цю тему.

Із набору програм з інтерфейсом командного рядка для моніторингу трафіку HTTP у нас є такі утиліти, як curl, tcpdump та tshark.

Використання HTTP у фреймворках та бібліотеках

Тепер, коли ми розглянули повідомлення запиту/відповіді, настав час ознайомитися з тим, який API бібліотеки та фреймворки надають для роботи з ними. Ми розглянемо приклади ExpressJS (для Node), Ruby on Rails та jQuery Ajax.

ExpressJS

Якщо ви створюєте веб-сервіси на Node.js, то напевне вже знайомі з ExpressJS. Прототипом ExpressJS був фреймворк для Ruby – Sinatra. Тому зрозуміло, що API ExpressJS подібний до його API.

Оскільки ми маємо справу з фреймворком для серверної частини, то при роботі з повідомленнями HTTP необхідно виконати дві дії:

Прочитати фрагменти URL-адреси і заголовки запиту.
Додати заголовки відповіді та тіло.

Розуміння HTTP дуже важливо для реалізації простого добротного RESTful (* веб-служби, побудовані з урахуванням REST (передавання стану представлення; архітектурний стиль взаємодії компонентів розподіленого додатка у мережі)) - інтерфейсу між двома кінцевими вузлами локальної мережі (* ЛМ).

ExpressJS як раз надає для цього простий API. Ми не будемо розглядати деталі API. Замість цього я дам вам посилання на детальну документацію з ExpressJS. Імена методів API у більшості випадків говорять самі за себе. Деякі приклади методів API, пов'язаних з обробленням запитів, наведено нижче:

req.body: для отримання тіла запиту.
req.query: для отримання фрагмента запиту URL.
req.originalUrl
req.host: для прочитання поля Host заголовка.
req.accepts: для отримання допустимих на стороні клієнта типів MIME (* багатоцільові розширення пошти (поштової служби) в Інтернеті; стандарт на кодування в одному повідомленні текстової і нетекстової інформації (наприклад, графіки) для передавання електронною поштою в Інтернеті).
req.get або req.header: для прочитання будь-якого поля заголовка, переданого у вигляді аргументу.

Для формування відповіді клієнтові ExpressJS надає наступний API:

res.status: для явного вказання коду стану.
res.set: для вказання певного заголовка.
res.send: для відправлення HTML, JSON або послідовності октетів.
res.sendFile: для передачі файлу клієнтові.
res.render: для виконання шаблону представлення Express.
res.redirect: для переадресації до іншого маршруту. Express автоматично додає код за налаштуванням про переадресацію 302.

Ruby on Rails

Формат повідомлень запиту та відповіді схожий (відмінності є у стартовому рядку та заголовках повідомлень).

У Rails модулі ActionController та ActionDispatch надають API для оброблення повідомлень запиту та відповіді.

ActionController надає високорівневий API для отримання URL-запиту, обробки результату та переадресації до іншого маршруту. Кінцева точка (маршрут) використовується для виконання вказаного у ньому методу (дії) (* наприклад, якщо користувач переходить за /clients/new у вашому застосунку для додавання нового клієнта, Rails створює зразок ClientsController та викликає його метод new). Більшість необхідної контекстної (* пов'язаної з конкретним запитом) інформації всередині методу стає доступною завдяки об'єктам request, response та params.

params: надає доступ до параметрів URL та даних, переданих за методом POST.
request: містить інформацію про клієнта, заголовки та URL.
response: використовується для встановлення значень заголовків та кодів стану.
render: для виконання шаблонів.
redirect_to: використовується для переадресації до іншого методу або на інший URL.

ActionDispatch надає тонко гранульований доступ до повідомлень запиту/відповіді за допомогою класів ActionDispatch::Request та ActionDispatch::Response. Цей модуль надає набір методів для перевірки типу запиту (get?(), post?(), head?(), local?()). Заголовки запиту можна напряму отримати за допомогою методу request.headers() .

Для роботи з відповіддю модуль надає методи cookies(), location=() та status=(). Якщо ви хочете поекспериментувати, то можете також задати тіло відповіді вручну за допомогою body=().

AJAX (* Asynchronous JavaScript And XML – асинхронний JavaScript + XML) jQuery

Оскільки jQuery – перед усім, бібліотека для клієнтської частини додатка, то API AJAX надає можливості, протилежні тим, що реалізуються на стороні сервера. Іншими словами, завдяки їй ви можете прочитувати та змінювати повідомлення запиту. jQuery надає доступ до простого API за допомогою jQuery.ajax(settings):

Передаючи об'єкт із налаштуваннями, до складу якого входить функція зворотного виклику beforeSend, ми можемо змінювати заголовки запиту. До неї передається об'єкт jqXHR (jQuery XMLHttpRequest), що має метод (setRequestHeader()) для встановлення значень заголовків.

$.ajax({
    url: 'http://www.articles.com/latest',
    type: 'GET',
    beforeSend: function (jqXHR) {
      jqXHR.setRequestHeader('Accepts-Language', 'en-US,en');
    }
  });

Об'єкт jqXHR також може бути використаний для прочитання заголовків відповіді за допомогою методу jqXHR.getResponseHeader().
Якщо ви хочете виконувати певні дії при надходженні різних кодів стану, то ви можете вказати функцію зворотного виклику в об'єкті statusCode.

$.ajax({
  statusCode: {
    404: function() {
      alert("page not found");
    }
  }
});

Резюме

Давайте тепер підсумуємо наш короткий розбір протоколу HTTP.

Ми ознайомилися зі структурою URL-адреси, методами та кодами стану – трьома китами комунікації за допомогою HTTP.

Формат повідомлень запиту та відповіді схожий (відмінності є у стартовому рядку та заголовках повідомлень). І, нарешті, ми розглянули, як ви можете використовувати заголовки запиту та відповіді у фреймворках та бібліотеках.

Розуміння HTTP дуже важливо для реалізації простого добротного RESTful - інтерфейсу між двома кінцевими вузлами локальної мережі (* ЛМ). Правду кажучи, ці знання вам також стануть у нагоді при створенні інфраструктури вашої мережі (* сукупність апаратних та програмних засобів, що надає користувачеві необхідні мережеві можливості) і забезпеченні для кінцевих користувачів зручності використання.

У другій частині ми розглянемо реалізацію з'єднань, автентифікацію та гешування! Тоді й побачимося.