2. • Протокол передачі даних, що використовується в компютерних мережах.
• Належить до протоколів моделі OSI 7-го прикладного рівня
• Основним призначенням протоколу HTTP є передача веб-сторінок
• Кожен запит/відповідь складається з трьох частин:
• стартовий рядок;
• заголовки;
• тіло повідомлення, що містить дані запиту, запитаний ресурс або опис проблеми, якщо запит не
виконано.
HTTP (Hyper Text Transfer Protocol)
3. • Сервер, що приймає HTTP-запити від клієнтів, зазвичай веб-браузерів, видає їм
HTTP-відповіді, зазвичай разом з HTML-сторінкою, зображенням, файлом, медіа-
потоком або іншими даними
• Клієнти дістаються веб-сервера за URL-адресою потрібної їм веб-сторінки або
іншого ресурсу
Веб-сервер
4. • Набір серверів для декількох служб Інтернету від компанії Майкрософт. IIS
поширюється з операційними системами родини Windows NT.
• Основний компонент IIS — веб-сервер, який дозволяє розміщувати в Інтернеті
сайти.
• Підтримує протоколи HTTP, HTTPS, FTP, POP3, SMTP, NNTP
• IIS 7.0 має модульну архітектуру.
• Конфігураційна інформація зберігається виключно в конфігураційних XML
IIS (Internet Information Services)
5. • Являє собою групування URL-адрес, які пересилається до одного або декількох
робочих процесів
• Оскільки пули додатків визначають набір веб-додатків, які використовують один
або кілька робочих процесів, вони забезпечують зручний спосіб адміністрування
набору веб-сайтів і додатків і відповідних робочих процесів
• Пули додатків значно підвищити як надійність і керованість веб-інфраструктури.
Application Pool
9. • Коли ми інсталюємо .NET, у відповідних директоріях C:WINDOWSMicrosoft.NETFramework
поміщається також файл aspnet_isapi.dll.
• Це - ISAPI-розширення, і призначене воно для отримання запитів, адресованих ASP .NET-
додаткам (* .aspx * .asmx і т.д.), а також для створення робочих процесів aspnet_wp.exe, які
обробляють запити.
• Інтернет-сервер - IIS або вбудований в WebMatrix і в Visual Studio Cassini - використовують це
розширення, коли їм треба обробити звернення до сторінок з розширенням ASPX.
Як працює ASP.NET
10. Як працює ASP.NET
• IIS завантажує додаток в пам’ять
• Для кожного запиту створюється новий потік
11. • Процес або код, який відповідає на HTTP запит
• Приклад
public class MyHttpHandler : IHttpHandler
{
public void ProcessRequest(HttpContext context)
{ context.Response.Write("I am а HTTP handler."); }
public bool IsReusable
{ get { return false; } }
}
• Реєстрація в web.config
<configuration><system.webServer><handlers>
<add verb="*" path="*.my" name=“My HTTP handler"
type=“MyHttpHandler"/>
</handlers></system.webServer></configuration>
HTTP Handlers
12. • HTTP Модулі - це класи, що реалізують інтерфейс IHttpModule і обробні події часу
виконання (Runtime).
• HTTP-модулі - це механізм, який дозволяє виконувати різні дії на будь-якому етапі
життєвого циклу сторінки або додатку.
• У HTTP-модулі можна підписатися на будь-яку подію життєвого циклу і обробляти
його, реалізуючи при цьому якусь свою логіку. Зазвичай, модулі використовують як
фільтри програми.
HTTP modules
13. • Кожен модуль запускається методом Init.
• У цьому методі кожен HTTP-модуль підписується на події життєвого циклу додатка
(BeginRequest, AuthenticateRequest ... - всього 26). Після цих дій всі завантажені
модулі HTTP залишаються в пам'яті і вивантажуються тільки тоді, коли
вивантажується домен додатка.
• При кожному циклі обробки запиту відпрацьовують ті чи інші події, на які підписані
різні HTTP-модулі. Саме в цей момент можна додати необхідну логіку.
HTTP modules
14. • Для того щоб створити власні HTTP-модулі необхідно створити клас, який реалізує
інтерфейс IHttpModule.
• В рамках цього інтерфейсу присутні два методу - Init () і Dispose ().
• Останній метод необхідний для того, щоб в потрібний момент очистити займані
ресурси. Зазвичай, цей метод залишається порожнім.
HTTP modules
15. • Метод Init () викликається в момент завантаження HTTP-модуля і має параметр типу
HttpApplication.
• Цей параметр дозволяє підписатися на події життєвого циклу обробки запиту
програми.
• Метод модуля Init () спрацьовує лише один раз - при створенні домена додатку..
HTTP modules
16. • Файл Global.asax (Global Class Application), або файл програми ASP.NET, є
додатковим файлом, що містить код для відгуку на події рівня додатка і рівня
сеансу, створюваний додатком ASP.NET або модулями HTTP.
• Файл Global.asax додається в кореневу папку програми ASP.NET.
• Під час виконання цей файл аналізується і компілюється в динамічно створюваний
клас .NET Framework, похідний від базового класу HttpApplication.
Global.asax
17. • Середовище ASP.NET налаштовується таким чином, що будь-який безпосередній
URL-запит до файлу Global.asax автоматично відхиляється, а зовнішні користувачі
не можуть завантажувати або переглядати код в ньому.
• Даний файл не є обов'язковим. Він створюється тільки в тому випадку, якщо
необхідна обробка подій додатка або сеансу.
Global.asax
18. • Application_Start - виникає коли створюється екземпляр класу HttpApplication.
• Session_start - виникає на початку кожного сеансу, тут можна форматувати змінні сеансу.
• Application_BeginRequest - ініціюється на початку кожного окремого запиту.
• Application_EndRequest - ініціюється в кінці запиту.
• Session_End - ініціюється в кінці кожного сеансу.
• Application_End - ініціюється перед видаленням екземпляра HttpApplication.
• Application_Error - ініціюється при будь-якому необробленому вийнятку в додатку.
Часто використовувані події
19. • Визначає параметри для ASP.NET веб-додатку, такі як DB connection strings, HTTP
handlers, modules, assembly bindings
• Може зберігати кастомні налаштування
• Зміни в файлі не вимагають рестарту
• Можна мати кілька конфіг файлів - один глобальний і кілька для різних папок
• Web.config наслідується з глобального Web.config і з machine.config
Web.config
20. • Web.debug.config
• Локальні налаштування для дебагу
• Напиклад локальна база даних для тестування
• Web.Release.config
• Налаштування для деплою на продакшн
Web.config
21. ASP.NET Core 1.0
• Попередня назва ASP.NET 5
• Кросс-платформний фреймворк з відкритим вихідним кодом.
• Оптимальний для хмарних веб-додатків
23. • Новий легка та модульна магістраль HTTP запитів
• Можливість хоститингу на IIS або само-хостинг і вашому власному процесі
• Будується на .NET Core, яке підтримує справжню side-by-side версійність програм
• Повністю постачається як NuGet пакет
• Інтегрована підтримка для створення і використання NuGet пакетів
• Одно-вирівняний веб стек для Web UI та Web APIs
• Базова конфігурація середовища готова для хмарних рішень
• Вбудована підтримка інєкції залежностей
• Нові засоби що спрощують сучасну веб розробку
• Компіляція та виконання крос-платворменних ASP.NET додатків на Windows, Mac and Linux
• Відкритий вихідний код
25. • Мережева технологія, що забезпечує міжпрограмну взаємодію на основі веб-
стандартів
• Програмна система, розроблену для підтримки інтероперабельнї міжкомп’ютерної
взаємодії через мережу
Веб сервіс
26. • Протокол, доступу до обєктів, оснований на обміні структурованими
повідомленнями
• Може використовуватись з будь яким протоколом прикладного рівня ( SMTP, FTP,
HTTP)
• Використання SOAP для передавання повідомлень збільшує їхній обсяг і знижує
швидкість обробки.
SOAP (Simple Object Access Protocol)
27. • Ідентификатор повідомлення (локальне ім’я).
• Опціональний елемент Header (заголовок):
Нуль або більше посилань на використовувані простори імен;
Нуль або більше властивостей, досткупних в цьому просторі імен
• Обовязковий елемент Body (тіло повідомлення)
Нуль або більше посилань на використовувані простори імен
Дочірні елементи тіла повідомлення
Структура протоколу SOAP
29. • Мова опису зовнішніх інтерфейсів і доступу до них, основана на XML
WSDL (Web Services Description Language)
30. • Щоб згенерувати WSDL файл для сервісу потрібно додати до урла сервісу
“?WSDL”: http://localhost/HelloService.asmx?WSDL
• Для використання сервісу в Visual Studio, його слід додати через Add Service
References…
• Якщо є тільки WSDL файл, використовуйте тулзу WSDL.exe
WSDL
31. • Інструмент для розміщення описів веб сервісів (WSDL) для пошуку їх іншими
організаціями і інтеграції в свої системи
• Кросплатформне пз основане на XML
• Призначений для запитів SOAP повідомленнями і забезпечення доступу до WSDL
документів, які описують привязки протоколів і форматів повідомлень, потрібних
для взаємодії з веб-послугами, які є в їхньому каталозі
UDDI (Universal Description Discovery &
Integration)
33. • Набір клієнтських бібліотек, що дозволяють застосункам на базі відкритої
платформи .NET Core взаємодіяти з сервісами WCF, відправляючи повідомлення
між сервісами в асинхронному режимі.
• WCF надає єдину інфраструктуру розробки, що підвищує продуктивність і знижує
витрати на створення веб-служб. Закладені в неї принципи інтероперабельності
дозволяють легко добиватися взаємодії з іншими платформами
WCF (Windows Communication Foundation)
34. • В основі три базових складники:
• Address - визначає куди слід відправляти повідомлення;
• Binding - визначає як необхідно відправляти повідомлення;
• Contract - визначає що має містити повідомлення.
• Web.config
WCF
35. • Клас служби WCF не може існувати самостійно. Кожна служба WCF повинна
перебувати під управлінням деякого процесу Windows, званого хостової процесом.
Існують кілька варіантів хостингу:
• Автохостинг (хост-процесом являється консольний або графічний Windows
додаток)
• Хостинг в одній з служб Windows
• Хостинг з використанням IIS або WAS
Хостинг WCF
36. • Клас служби WCF не може існувати самостійно. Кожна служба WCF повинна
перебувати під управлінням деякого процесу Windows, званого хостової процесом.
Існують кілька варіантів хостингу:
• Автохостинг (хост-процесом являється консольний або графічний Windows
додаток)
• Хостинг в одній з служб Windows
• Хостинг з використанням IIS або WAS
Хостинг WCF
37. • REpresentational State Transfer (назва не відповідає суті)
• Архітектурний паттерн, а не стандарт
• Стано-незалежний (Stateless), клієнт-серверний, кешований протокол звязку
• Використання HTTP запитів для відправки, читання і видалення даних
• Полегшений
• Іменники як URI, дієслова як HTTP метод
REST
38. • Ресурси
• Все, що досить важливо щоб мати власне посилання.
• Може бути фізичний об’єкт або абстрактний концепт.
• Кожен ресурс має принаймні одне ім’я
• Ресурси можуть бути контейнерами інших ресурсів
• Контейнери завжди є ресурсами
• Паттерн Композит (Composite design pattern)
Ресурси і контейнери
39. • Дозволяє створити структуру дерева і задати кожному елементу в структурі
дерева, виконати завдання.
Composite design pattern
40. • Репрезентація ресурсів
• Будь яка корисна інформація про стан ресурсу
• Визначається за допомогою певного URL або узгодження контенту через заголовки канонічного URI ресурсів.
• Канонічний URI ресурсів
• Незалежно від формату або локальної мови
• Може бути визначено в Content-Location заголовку репрезентативної відповіді
Репрезентація ресурсів
42. • Адресація
• Ресурси ідентифікуються по URI
• Відсутність станів
• Відсутність станів звязку, що утримуються між REST викликами
• Звязність
• Ресурси повинні бути повязані разом в їхньому представленні
• Однаковий інтерфейс
• HTTP GET, PUT, POST, DELETE, HEAD, OPTIONS
• HTTP method header
• HTTP status codes
Ресурсно-орієнтовна архітектура
43. • Ім’я і адреса ресурсу
• Оглядова інформація про ресурс
• Принципи адресації
• Повинна бути описова
• Унікальні URI незахищені для кожного ресурсу доступні з RESTful системи
• Кожен URI позначає рівно один ресурс
• URIs доступними для ваших клієнтів
Адресація через URI
44. • Відсутність станів, що зберігаються на сервері
• Кожен HTTP запит виконується на сервері в повній ізоляції
• Спрощене проектування і розвиток
• Полегшене масштабування
• Уникайте використання HTTP сесій і куків
• Відсутність побічних ефектів
Відсутність станів
45. • Стандартизовані
• GET
• POST
• PUT
• DELETE
• HEAD
• OPTIONS
• Репрезентують виклик дії
• Ресурси відображають однаковий інтерфейс
HTTP методи (дії)
46. GET
Client Browser
GET /v1/users/10548
HTTP Status: 200 (ОК)
Response headers
Requested representation
Web Server
HEAD
Client Browser
HEAD /v1/users/10548
HTTP Status: 200 (ОК)
Response headers
Web Server
47. PUT
Client Browser
PUT /v1/users/10548
HTTP Status: 200 (ОК)
Response headers
Web Server
DELETE
Client Browser
DELETE /v1/users/10548
HTTP Status: 200 (ОК)
Response headers
Web Server
49. • Основні засоби звітів про результати REST операції
• Використовуйте тіло об'єкта, щоб додати допоміжні визначники до результату
• Не відправляйте назад репрезентацію ресурсів на жоден з методів окрім GET, задля
забезпечення відсутності негативного впливу на оптимізацію продуктивності
HTTP статус коди
50. • 100 Continue
• 200 OK
• 201 Created
• 204 No Content
• 304 Not Modified
• 400 Bad Request
• 401 Unauthorized
• 400 Bad Request
• 404 Not Found
• 409 Conflict
• 500 Internal Server Error
Топ 10 HTTP статус кодів
51. • GET I HEAD запити не повинні викликати жодних катастрофічних ефектів на
серверній стороні
• Відсутність побічних ефектів
• Клієнт не повинен робити запитів тільки для погашення побічних ефектів
• Уникайте впливу небезпечних (unsafe) операцій через GET
Безпека
52. • Багаторазовий виклик результатів операцій дає той самий результат в тому ж
результуючому стані, як і результат одного виклику
• Ідемпотентні методи: GET, HEAD, PUT, DELETE , OPTIONS
• Не ідемпотентні: POST
Ідемпотентність
53. • Під час створення і оновлення ресурсів
• PUT, якщо, і тільки якщо, ви можете повністю вказати повний вміст ресурсу
• POST, якщо ви відправляєте команду, щоб створити або оновити один або кілька підлеглих зазначеного
ресурсу
• За допомогою POST, сервер буде визначати URI ресурсу
• Використовуйте заголовок Location в POST запиті, щоб вказати нові URI езурсів,
якщо доступно
PUT vs POST
54. • HTTPS i SSL сертифікату валідація
• 5 головних HTTP методів: GET, HEAD, POST, PUT, DELETE
• Кастомізація даних, що відправляються в тілі обєкту PUT або POST запиту
• Доступ до статус коду та заголовків відповіді
• Комунікація через HTTP проксі
Вимоги до HTTP клієнта
55. • Передача і обробка стиснених даних
• Запит: заголовок Accept Encoding
• Відповідь: заголовок Encoding
• Кешування відповідей на запит
• Запити GET з станом
• Загальна форма HTTP аутентифікації (Basic, Digest, WSSE)
• Прозоре слідування HTTP переадресації
Опціональна функціональність
HTTP клієнта
56. • Ієрархічна
• Кодуй дані в «змінні шляху» в URI
• http: //maps.example.com/Earth/Europe/France/Paris
• Не ієрархічна
• Комбінуються в одну змінну шляху, розділені комою або крапкою з комою
• Використовуй кому, коли порядок важливий, крапку з комою в іншому випадку
• http: //maps.example.com/Earth/24,158,89,515
• Алгоритмічні ресурси
• Використання змінних запиту
• http://www.google.com/search?q=rest
Побудова URI
57. • Версія вашого сервісу
• Вбудова версії в URI
• GET /v1/users/234234
• Репрезентація також повинна підлягати версійності
• Втавляйте інформацію про версію в репрезентацію
Версійність REST API
58. • Більшість ресурсів не сильно змінюється
• Зберігає клієнтський і серверний час виконання і пропускну здатність мережі
• Реалізовано використовуючи HTTP заголовки
• Заголовки відповіді: Last-Modified i Etag
• Заголовки запиту: If-Modified-Since i If-None-Match
Conditional GET
59. Conditional GET
Client Browser
GET /v1/users/10548
If-Modified-Since: <cached Last-Modified value>
If-None-Match: <cached Etag value>
HTTP Status: 304 (Not Modified)
Response headers
Web Server
Continue to
used cached
representation
1
23
60. • Ресурси можуть зберігатись в різних репрезентаціях (XML, JSON, HTML...)
• Методи узгодження контенту:
• Заголовки (Accept або Content-Type)
• Query parameter (GET /v1/users/10505?format=json)
• URI extension (GET /v1/users/10505.xml)
Узгодження контенту
61. • Використання REST як RPC-подібний механізм
• Надмірне використання POST
• Вставляння дій в URI
• Маскування сервісу як ресурсу
• Управління сесіями на сервері
Загальні помилки
