www.wikidata.uk-ua.nina.az

REST скор англ Representational State Transfer передача репрезентативного стану підхід до архітектури мережевих протокол

REST

REST (скор. англ. Representational State Transfer, «передача репрезентативного стану») — підхід до архітектури мережевих протоколів, які надають доступ до інформаційних ресурсів. Був описаний і популяризований 2000 року Роєм Філдінгом, одним із творців протоколу HTTP. В основі REST закладено принципи функціонування Всесвітньої павутини і, зокрема, можливості HTTP. Філдінг розробив REST паралельно з HTTP 1.1 базуючись на попередньому протоколі HTTP 1.0.

Дані повинні передаватися у вигляді невеликої кількості стандартних форматів (наприклад, HTML, XML, JSON). Будь-який REST протокол (HTTP в тому числі) повинен підтримувати кешування, не повинен залежати від мережевого прошарку, не повинен зберігати інформації про стан між парами «запит-відповідь». Стверджується, що такий підхід забезпечує масштабовність системи і дозволяє їй еволюціонувати з новими вимогами.

Антиподом REST є підхід, заснований на виклику віддалених процедур (Remote Procedure Call, RPC). Підхід RPC дозволяє використовувати невелику кількість мережевих ресурсів з великою кількістю методів і складним протоколом. При підході REST кількість методів і складність протоколу суворо обмежені, що призводить до того, що кількість окремих ресурсів має бути великою.


REST — це архітектурний стиль для розподілених гіпертекстових систем.

Архітектурні обмеження Редагувати

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

Клієнт-сервер Редагувати

Перша архітектура від якої він успадковує обмеження — це клієнт-серверна архітектура. Її обмеження вимагає розділення відповідальності[en] між компонентами, які займаються зберіганням та оновленням даних (сервером), і тими компонентами, які займаються відображенням даних на інтерфейсі користувача та реагування на дії з цим інтерфейсом (клієнтом). Таке розділення дозволяє компонентам еволюціонувати незалежно.

Відсутність стану Редагувати

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

Обмеження "відсутність стану" не означає, що архітектура REST дозволяє будувати лише системи, в яких немає стану[en]. Відсутність стану означає, що сервер не знає про стан клієнта і не повинен запам'ятовувати послідовність здійснених до нього запитів, тому що кожен з них є незалежним. Коли клієнт, наприклад, запитує головну сторінку сайту, сервер відповідає на запитання і забуває про клієнта. Клієнт може залишити сторінку відкритою протягом кількох років, перш ніж натиснути посилання, і тоді сервер відповість на інший запит. Тим часом сервер може відповідати на запити інших клієнтів, або нічого не робити — для клієнта це не має значення.

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

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

Кешування Редагувати

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

Рання архітектура веб, створена Тімом Бернерсом-Лі відповідала цим трьом обмеженням — клієнт-сервер без стану з підтримкою кешування. Проте, стиль REST додає ще додаткові обмеження.

Однорідний інтерфейс Редагувати

Всі компоненти в архітектурі REST підтримують однорідний інтерфейс. Це зменшує зв'язність між компонентами і сервісами які вони надають і дозволяє нескладно змінювати компоненти при потребі. Це досягається кількома точнішими обмеженнями:

Цей розділ потребує доповнення. (лютий 2017)
  • ідентифікація ресурсів: URI запит повинен точно визначати ресурс, що очікується та якого формату повинна бути відповідь. У відповідь на запит клієнту надається представлення ресурсу. Ресурси концептуально відділені від представлення. Наприклад, сервер може надсилати дані із бази даних в форматі HTML, XML або JSON, жоден з яких не є типом даних, що зберігаються всередині сервера.
  • маніпуляція ресурсами через представлення: якщо клієнт має представлення ресурсу, включаючи метадані, він має достатньо інформації, щоб модифікувати або видаляти цей ресурс.
  • самоописові повідомлення: кожне повідомлення має містити достатньо інформації для його обробки. Наприклад, обробник (parser), що використовується для розшифровки даних, може бути вказаний у списку MIME типів.
  • гіпермедіа як рушій стану застосунку (HATEOAS): Клієнт, що має доступ до REST сервісу, повинен отримати всі наявні сервіси та методи за допомогою гіперпосилань.

Шари абстракції Редагувати

Наступним обмеженням для REST є поділ на шари абстракції. Кожен компонент потрапляє в якийсь шар і спілкується лише з компонентами в шарі під ним або в шарі над ним. Обмеження знання системи одним шаром зменшує складність компонентів.

Запитування коду Редагувати

Останнім архітектурним обмеженням в REST є те що клієнти повинні дозволяти розширювати свою функціональність дозволяючи завантаження додаткового коду (code on demand[en]) в формі аплетів чи скриптів. Це спрощує клієнти, дозволяючи не реалізовувати всі необхідні функції попередньо. Щоправда це необов'язкове обмеження, і якщо воно не дає переваг для конкретного застосування, то його не обов'язково реалізовувати. Наприклад, дозвіл завантаження стороннього коду може бути не бажаним з точки зору безпеки.

Архітектурні елементи Редагувати

Елементи даних Редагувати

Компоненти REST системи спілкуються, передаючи один одному представлення ресурсу в форматі, що обирається з оновлюваного набору стандартних форматів даних. Формат обирається динамічно відповідно до бажань компонента-клієнта і можливостей сервера. Чи представлення має той самий формат, що й сам ресурс, чи є результатом якогось перетворення — це деталь реалізації, яка ховається за інтерфейсом.

Ресурс Редагувати

Ресурс — це ключовий елемент даних в REST. Ресурсом може бути що завгодно що можна назвати: якийсь документ (наприклад зображення), динамічне значення (наприклад погода у Львові), щось з реального світу (наприклад працівник компанії). Але якщо точніше, то ресурс  — це функція приналежності що відображає моменти в часі на множину однотипних сутностей чи значень. Множина може бути порожньою, тобто REST дозволяє посилання на якийсь об'єкт якого ще не існує.

Ресурс може бути динамічним, наприклад ресурс «стаття про REST у вікіпедії» час від часу оновлює свій вміст, а може бути статичним, і після появи ніколи не змінювати свого значення, наприклад «перша версія статті про REST у вікіпедії». У REST такі два ресурси вважаються різними, хоча в певний момент часу вони можуть вказувати на одну й ту ж сутність. Єдине що важливо — семантика відображення імені ресурсу на його вміст.

Ідентифікатор ресурсу Редагувати

Для того, щоб посилатись на ресурси, використовуються ідентифікатори ресурсів. Компонент, який надав ресурсу ідентифікатор і дозволяє звертатись до нього за цим ідентифікатором, відповідає за збереження функції приналежності незмінною. Якість ідентифікатора залежить від якості компонента, який цей ідентифікатор надає, тому деякі ідентифікатори стають «мертвими посиланнями», коли інформацію переміщують або знищують.

Приклади ідентифікаторів ресурсу: URL, URN.

Представлення Редагувати

Представлення (англ. representation) — це послідовність байтів та метадані представлення, для того щоб описати ці байти. Часто, представлення називають документом, файлом, повідомленням HTTP тощо

Приклади представлення: фотографія JPEG, документ HTML. Приклад метаданих представлення — тип медіа, час останньої зміни.

Метадані також можуть бути не лише в представлення ресурсу, а й в самого ресурсу. Прикладами метаданих ресурсу є посилання на джерело, <link rel="alternates" ... />, заголовок HTTP vary.

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

Також, контрольні дані, включені в запити чи відповіді, можуть керувати поведінкою кешу. Прикладом таких контрольних даних можуть бути заголовки HTTP if-modified-since та cache-control.

Формат даних представлення називають типом медіа (англ. media type). Одні типи медіа краще підходять для автоматичної обробки, інші — для того щоб бути показаними користувачу. Композитні типи медіа можуть використовуватись для того, аби поєднати кілька видів представлення в одному.

Від формату даних дуже залежить латентність застосунку, яку сприймає користувач. Наприклад, браузер може почати показувати сторінку ще до того, як завантажиться ввесь HTML, це збільшує видиму швидкість роботи.

Конектори Редагувати

Конектори надають інтерфейс для комунікації компонентів, приховуючи реалізації ресурсів та механізм комунікації.

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

Двома найважливішими типами конекторів є клієнт і сервер. Відмінністю між ними є те що клієнт ініціює запит, в той час як сервер очікує запитів і відповідає на них даючи доступ до своїх сервісів. Компонент може містити одночасно як серверні так і клієнтські конектори.

Додатковим типом конектора є кеш. Кеш може бути як клієнтським, для уникнення зайвих запитів, так і серверним — для уникнення зайвого обчислення відповіді на запит. Тому що інтерфейс однорідний, кеш легко може дізнатись чи запит можна кешувати. За замовчуванням, відповідь на запит отримання ресурсу можна кешувати, а запити зміни ресурсу — ні. Проте ці замовчування можна перевантажити контрольними даними.

Резолвер (англ. resolver) — це ще один тип конектора, який перетворює ідентифікатори ресурсів в інформацію про мережеві адреси необхідну компонентам щоб отримати цей ресурс. Наприклад в URI міститься доменне ім'я, і для доступу до відповідного домену, потрібно дізнатись в DNS-сервера адресу. Тому в цьому випадку система DNS грає роль резолвера. Використання одного чи кількох резолверів може збільшити життєздатність ідентифікатора ресурсу, через те що він не вказує напряму на фізичне розташування ресурсу яке може змінитись.

Останньою формою конектора є тунель, який просто проводить запити через межу системи, наприклад, через фаєрвол. Причиною, через яку тунелі включено до архітектури REST, а не закрито абстракцією мережі, є те, що певні компоненти можуть перетворюватись на тунелі за запитом. Наприклад тунель HTTP[en] активується при отриманні запиту з методом CONNECT.

Компоненти Редагувати

Цей розділ потребує доповнення. (лютий 2017)


Семантика протоколу HTTP Редагувати

Типове використання HTTP методів:

HTTP методи
URL GET PUT PATCH POST DELETE
Колекція https://api.example.com/resources/ Повертає URI та можливо інші деталі ресурсів колекції. Замінює одну колекцію іншою. Зазвичай не використовують Створює новий ресурс в колекції. URI для нового ресурсу застосунок призначає автоматично та зазвичай повертає у відповіді. Видаляє всю колекцію.
Ресурс https://api.example.com/resources/item17 Повертає представлення ресурсу колекції. Замінює певний ресурс колекції, і якщо він не існує, створює його. Оновлює певний ресурс колекції. Зазвичай не використовують Видаляє певний ресурс колекції.


Хоча ресурс може бути яким завгодно, дії, які можна виконувати над ресурсом, визначаються повідомленнями, які визначено стандартним протоколом. В системі WWW цей протокол — HTTP, але існують REST-архітектури на основі й інших протоколів.

Стандарт HTTP визначає 8 типів повідомлень.

Найчастіше використовують 4 з них:

  • GET — отримати представлення ресурсу
  • DELETE — знищити ресурс
  • POST — створити новий ресурс на місці даного використавши передане представлення
  • PUT — замінити стан поточного ресурсу станом, що описується переданим представленням

Ці використовуються, щоб дослідити API:

  • HEAD — отримати заголовки, які б відсилались разом з представленням цього ресурсу, але не саме представлення.
  • OPTIONS — визначити список методів, на які цей ресурс відповідає.

Інші два методи, CONNECT та TRACE, використовуються лише для HTTP-проксі.

Існує також дев'ятий метод, щоправда, описаний не в HTTP, а в додатку RFC 5789:

PATCH — змінити лише частину цього ресурсу на основі даного представлення. Якщо якась частина ресурсу не згадується в переданому представленні — не чіпати її. Це знижує кількість інформації, яку потрібно передавати.

Ще два методи описуються в пропозиції до стандарту «Internet-Draft „snell-link-method“»:

  • LINK — прив'язати певний ресурс до цього
  • UNLINK — відв'язати ресурс від цього

Методи GET, PUT та DELETE — ідемпотентні, що означає, що незалежно від того, скільки разів ви виконаєте операцію, яку вони просять, — ви отримаєте той самий результат. Звісно, спершу DELETE поверне 204 No Content, а потім 404 Not Found, але ресурсу не буде, що після одного видалення, що після десяти. Ідемпотентність є дуже важливою в мережі, де ви не знаєте, чи досяг запит успіху, і, не отримавши відповіді, надсилаєте його ще раз. POST — не ідемпотентний, тобто, відправивши POST на створення повідомлення кілька разів, ви отримаєте кілька повідомлень.

URI Templates[en] описуються в RFC 6570, і виглядають так: 

https://uk.wikipedia.org/w/index.php?search={search}

Див. також Редагувати

Примітки Редагувати

  1. ↑ Fielding, 2000, с. 76.
  2. Fielding, 2000, с. 78.
  3. Fielding, 2000, с. 79.
  4. Fielding, 2000, с. 80.
  5. Fielding, 2000, с. 81.
  6. Fielding, 2000, с. 82.
  7. Fielding, 2000, с. 84.
  8. Fielding, 2000, с. 85.
  9. ↑ Fielding, 2000, с. 88.
  10. Fielding, 2000, с. 89.
  11. ↑ Fielding, 2000, с. 90.
  12. . Архів оригіналу за 27 грудня 2016. Процитовано 14 лютого 2017. 
  13. . Архів оригіналу за 25 травня 2017. Процитовано 14 лютого 2017. 
  14. Fielding, 2000, с. 92.
  15. Fielding, 2000, с. 94.
  16. ↑ Fielding, 2000, с. 95.
  17. Помилка цитування: Неправильний виклик тегу <ref>: для виносок під назвою thereisnorightway не вказано текст
  18. Richardson, Amundsen та Ruby, 2013, с. 33.
  19. Richardson, Amundsen та Ruby, 2013, с. 36.
  20. Richardson, Amundsen та Ruby, 2013, с. 49.

Література Редагувати

Посилання Редагувати

Вікіпедія, Українська, Україна, книга, книги, бібліотека, стаття, читати, завантажити, безкоштовно, безкоштовно завантажити, mp3, відео, mp4, 3gp, jpg, jpeg, gif, png, малюнок, музика, пісня, фільм, книга, гра, ігри
Дата публікації:
REST skor angl Representational State Transfer peredacha reprezentativnogo stanu pidhid do arhitekturi merezhevih protokoliv yaki nadayut dostup do informacijnih resursiv Buv opisanij i populyarizovanij 2000 roku Royem Fildingom odnim iz tvorciv protokolu HTTP V osnovi REST zakladeno principi funkcionuvannya Vsesvitnoyi pavutini i zokrema mozhlivosti HTTP Filding rozrobiv REST paralelno z HTTP 1 1 bazuyuchis na poperednomu protokoli HTTP 1 0 Dani povinni peredavatisya u viglyadi nevelikoyi kilkosti standartnih formativ napriklad HTML XML JSON Bud yakij REST protokol HTTP v tomu chisli povinen pidtrimuvati keshuvannya ne povinen zalezhati vid merezhevogo prosharku ne povinen zberigati informaciyi pro stan mizh parami zapit vidpovid Stverdzhuyetsya sho takij pidhid zabezpechuye masshtabovnist sistemi i dozvolyaye yij evolyucionuvati z novimi vimogami Antipodom REST ye pidhid zasnovanij na vikliku viddalenih procedur Remote Procedure Call RPC Pidhid RPC dozvolyaye vikoristovuvati neveliku kilkist merezhevih resursiv z velikoyu kilkistyu metodiv i skladnim protokolom Pri pidhodi REST kilkist metodiv i skladnist protokolu suvoro obmezheni sho prizvodit do togo sho kilkist okremih resursiv maye buti velikoyu REST ce arhitekturnij stil dlya rozpodilenih gipertekstovih sistem 1 Zmist 1 Arhitekturni obmezhennya 1 1 Kliyent server 1 2 Vidsutnist stanu 1 3 Keshuvannya 1 4 Odnoridnij interfejs 1 5 Shari abstrakciyi 1 6 Zapituvannya kodu 2 Arhitekturni elementi 2 1 Elementi danih 2 1 1 Resurs 2 1 2 Identifikator resursu 2 1 3 Predstavlennya 2 2 Konektori 2 3 Komponenti 3 Semantika protokolu HTTP 4 Div takozh 5 Primitki 6 Literatura 7 PosilannyaArhitekturni obmezhennya RedaguvatiREST yak i kozhen arhitekturnij stil vidpovidaye ryadu arhitekturnih obmezhen angl architectural constraints Ce gibridnij stil yakij uspadkovuye obmezhennya z inshih arhitekturnih stiliv 1 Kliyent server Redaguvati Persha arhitektura vid yakoyi vin uspadkovuye obmezhennya ce kliyent serverna arhitektura Yiyi obmezhennya vimagaye rozdilennya vidpovidalnosti en mizh komponentami yaki zajmayutsya zberigannyam ta onovlennyam danih serverom i timi komponentami yaki zajmayutsya vidobrazhennyam danih na interfejsi koristuvacha ta reaguvannya na diyi z cim interfejsom kliyentom Take rozdilennya dozvolyaye komponentam evolyucionuvati nezalezhno Vidsutnist stanu Redaguvati Nastupnim obmezhennyam ye te sho vzayemodiyi mizh serverom ta kliyentom ne mayut stanu tobto kozhen zapit mistit vsyu neobhidnu informaciyu dlya jogo obrobki i ne pokladayetsya na te sho server znaye shos z poperednogo zapitu Obmezhennya vidsutnist stanu ne oznachaye sho arhitektura REST dozvolyaye buduvati lishe sistemi v yakih nemaye stanu en Vidsutnist stanu oznachaye sho server ne znaye pro stan kliyenta i ne povinen zapam yatovuvati poslidovnist zdijsnenih do nogo zapitiv tomu sho kozhen z nih ye nezalezhnim Koli kliyent napriklad zapituye golovnu storinku sajtu server vidpovidaye na zapitannya i zabuvaye pro kliyenta Kliyent mozhe zalishiti storinku vidkritoyu protyagom kilkoh rokiv persh nizh natisnuti posilannya i todi server vidpovist na inshij zapit Tim chasom server mozhe vidpovidati na zapiti inshih kliyentiv abo nichogo ne robiti dlya kliyenta ce ne maye znachennya Takim chinom napriklad dani pro stan sesiyi koristuvacha yakij avtentifikuvavsya zberigayutsya na kliyenti i peredayutsya z kozhnim zapitom Ce pokrashuye masshtabovnist bo server pislya zakinchennya obrobki zapitu mozhe zvilniti vsi resursi zadiyani dlya ciyeyi operaciyi bez zhodnogo riziku vtratiti cinnu informaciyu Takozh sproshuyetsya monitoring i znevadzhennya bo dlya togo abi rozibratis u tomu sho vidbuvayetsya v pevnomu zapiti dosit podivitis lishe na cej zapit Zbilshuyetsya nadijnist bo pomilka v odnomu zapiti ne zachipaye inshi 2 Minusom cogo obmezhennya ye te sho znizhuyetsya produktivnist cherez te sho v kozhen zapit teper dovoditsya dodavati dani sesiyi z kliyenta Takozh zberezhennya stanu na riznih kliyentah vazhche pidtrimuvati bo realizaciyi kliyentiv mozhut vidriznyatis todi yak seredovishe servera povnistyu pid kontrolem rozrobnika 3 Keshuvannya Redaguvati Dodatkovim obmezhennyam stilyu REST ye te sho sistemi napisani v comu stili povinni pidtrimuvati keshuvannya tobto dani yaki peredayutsya serverom povinni mistiti informaciyu pro te chi mozhna yih keshuvati i yaksho mozhna to yak dovgo Ce dozvolyaye zbilshuvati produktivnist unikayuchi zajvih zapitiv ale takozh zmenshuye nadijnist sistemi cherez te sho dani v keshi mozhut zastariti Rannya arhitektura veb stvorena Timom Bernersom Li vidpovidala cim trom obmezhennyam kliyent server bez stanu z pidtrimkoyu keshuvannya 4 Prote stil REST dodaye she dodatkovi obmezhennya Odnoridnij interfejs Redaguvati Vsi komponenti v arhitekturi REST pidtrimuyut odnoridnij interfejs Ce zmenshuye zv yaznist mizh komponentami i servisami yaki voni nadayut i dozvolyaye neskladno zminyuvati komponenti pri potrebi 5 Ce dosyagayetsya kilkoma tochnishimi obmezhennyami Cej rozdil potrebuye dopovnennya lyutij 2017 identifikaciya resursiv URI zapit povinen tochno viznachati resurs sho ochikuyetsya ta yakogo formatu povinna buti vidpovid U vidpovid na zapit kliyentu nadayetsya predstavlennya resursu Resursi konceptualno viddileni vid predstavlennya Napriklad server mozhe nadsilati dani iz bazi danih v formati HTML XML abo JSON zhoden z yakih ne ye tipom danih sho zberigayutsya vseredini servera manipulyaciya resursami cherez predstavlennya yaksho kliyent maye predstavlennya resursu vklyuchayuchi metadani vin maye dostatno informaciyi shob modifikuvati abo vidalyati cej resurs samoopisovi povidomlennya kozhne povidomlennya maye mistiti dostatno informaciyi dlya jogo obrobki Napriklad obrobnik parser sho vikoristovuyetsya dlya rozshifrovki danih mozhe buti vkazanij u spisku MIME tipiv gipermedia yak rushij stanu zastosunku HATEOAS Kliyent sho maye dostup do REST servisu povinen otrimati vsi nayavni servisi ta metodi za dopomogoyu giperposilan Shari abstrakciyi Redaguvati Nastupnim obmezhennyam dlya REST ye podil na shari abstrakciyi Kozhen komponent potraplyaye v yakijs shar i spilkuyetsya lishe z komponentami v shari pid nim abo v shari nad nim Obmezhennya znannya sistemi odnim sharom zmenshuye skladnist komponentiv 6 Zapituvannya kodu Redaguvati Ostannim arhitekturnim obmezhennyam v REST ye te sho kliyenti povinni dozvolyati rozshiryuvati svoyu funkcionalnist dozvolyayuchi zavantazhennya dodatkovogo kodu code on demand en v formi apletiv chi skriptiv Ce sproshuye kliyenti dozvolyayuchi ne realizovuvati vsi neobhidni funkciyi poperedno Shopravda ce neobov yazkove obmezhennya i yaksho vono ne daye perevag dlya konkretnogo zastosuvannya to jogo ne obov yazkovo realizovuvati Napriklad dozvil zavantazhennya storonnogo kodu mozhe buti ne bazhanim z tochki zoru bezpeki 7 Arhitekturni elementi RedaguvatiElementi danih Redaguvati Komponenti REST sistemi spilkuyutsya peredayuchi odin odnomu predstavlennya resursu v formati sho obirayetsya z onovlyuvanogo naboru standartnih formativ danih Format obirayetsya dinamichno vidpovidno do bazhan komponenta kliyenta i mozhlivostej servera Chi predstavlennya maye toj samij format sho j sam resurs chi ye rezultatom yakogos peretvorennya ce detal realizaciyi yaka hovayetsya za interfejsom 8 Resurs Redaguvati Resurs ce klyuchovij element danih v REST Resursom mozhe buti sho zavgodno sho mozhna nazvati yakijs dokument napriklad zobrazhennya dinamichne znachennya napriklad pogoda u Lvovi shos z realnogo svitu napriklad pracivnik kompaniyi Ale yaksho tochnishe to resurs R displaystyle R nbsp ce funkciya prinalezhnosti M R t displaystyle M R t nbsp sho vidobrazhaye momenti v chasi na mnozhinu odnotipnih sutnostej chi znachen Mnozhina mozhe buti porozhnoyu tobto REST dozvolyaye posilannya na yakijs ob yekt yakogo she ne isnuye 9 Resurs mozhe buti dinamichnim napriklad resurs stattya pro REST u vikipediyi chas vid chasu onovlyuye svij vmist a mozhe buti statichnim i pislya poyavi nikoli ne zminyuvati svogo znachennya napriklad persha versiya statti pro REST u vikipediyi U REST taki dva resursi vvazhayutsya riznimi hocha v pevnij moment chasu voni mozhut vkazuvati na odnu j tu zh sutnist Yedine sho vazhlivo semantika vidobrazhennya imeni resursu na jogo vmist 10 Identifikator resursu Redaguvati Dlya togo shob posilatis na resursi vikoristovuyutsya identifikatori resursiv Komponent yakij nadav resursu identifikator i dozvolyaye zvertatis do nogo za cim identifikatorom vidpovidaye za zberezhennya funkciyi prinalezhnosti nezminnoyu Yakist identifikatora zalezhit vid yakosti komponenta yakij cej identifikator nadaye tomu deyaki identifikatori stayut mertvimi posilannyami koli informaciyu peremishuyut abo znishuyut 11 Prikladi identifikatoriv resursu URL URN Predstavlennya Redaguvati Predstavlennya angl representation ce poslidovnist bajtiv ta metadani predstavlennya dlya togo shob opisati ci bajti Chasto predstavlennya nazivayut dokumentom fajlom povidomlennyam HTTP toshoPrikladi predstavlennya fotografiya JPEG dokument HTML Priklad metadanih predstavlennya tip media chas ostannoyi zmini Metadani takozh mozhut buti ne lishe v predstavlennya resursu a j v samogo resursu Prikladami metadanih resursu ye posilannya na dzherelo span class p lt span span class nt link span span class na rel span span class o span span class s alternates span span class err span span class p gt span 12 zagolovok HTTP vary 13 9 Kontrolni dani v predstavlenni opisuyut cil povidomlennya mizh komponentami napriklad prohannya pro diyu stvoriti zminiti vidaliti resurs abo znachennya vidpovidi napriklad potochnij stan resursu chi znachennya yakogos inshogo resursu napriklad opis pomilki Takozh kontrolni dani vklyucheni v zapiti chi vidpovidi mozhut keruvati povedinkoyu keshu 11 Prikladom takih kontrolnih danih mozhut buti zagolovki HTTP if modified since ta cache control Format danih predstavlennya nazivayut tipom media angl media type Odni tipi media krashe pidhodyat dlya avtomatichnoyi obrobki inshi dlya togo shob buti pokazanimi koristuvachu Kompozitni tipi media mozhut vikoristovuvatis dlya togo abi poyednati kilka vidiv predstavlennya v odnomu Vid formatu danih duzhe zalezhit latentnist zastosunku yaku sprijmaye koristuvach Napriklad brauzer mozhe pochati pokazuvati storinku she do togo yak zavantazhitsya vves HTML ce zbilshuye vidimu shvidkist roboti 14 Konektori Redaguvati Konektori nadayut interfejs dlya komunikaciyi komponentiv prihovuyuchi realizaciyi resursiv ta mehanizm komunikaciyi Konektori podibni na viddalenij viklik procedur ale z pevnimi nyuansami shodo peredachi parametriv ta rezultatu vikliku Parametri skladayutsya z identifikatora resursu kontrolnih danih ta neobov yazkovo predstavlennya Rezultat z kontrolnih danih vidpovidi i predstavlennya Mozhna abstraguvatis i vvazhati takij viklik sinhronnim ale naspravdi peredacha danih vidbuvayetsya potokovo tomu obrobku danih mozhna pochinati she do togo yak otrimani vsi dani takim chinom zmenshuyuchi latentnist Dvoma najvazhlivishimi tipami konektoriv ye kliyent i server Vidminnistyu mizh nimi ye te sho kliyent iniciyuye zapit v toj chas yak server ochikuye zapitiv i vidpovidaye na nih dayuchi dostup do svoyih servisiv Komponent mozhe mistiti odnochasno yak serverni tak i kliyentski konektori 15 Dodatkovim tipom konektora ye kesh Kesh mozhe buti yak kliyentskim dlya uniknennya zajvih zapitiv tak i servernim dlya uniknennya zajvogo obchislennya vidpovidi na zapit Tomu sho interfejs odnoridnij kesh legko mozhe diznatis chi zapit mozhna keshuvati Za zamovchuvannyam vidpovid na zapit otrimannya resursu mozhna keshuvati a zapiti zmini resursu ni Prote ci zamovchuvannya mozhna perevantazhiti kontrolnimi danimi 16 Rezolver angl resolver ce she odin tip konektora yakij peretvoryuye identifikatori resursiv v informaciyu pro merezhevi adresi neobhidnu komponentam shob otrimati cej resurs Napriklad v URI mistitsya domenne im ya i dlya dostupu do vidpovidnogo domenu potribno diznatis v DNS servera adresu Tomu v comu vipadku sistema DNS graye rol rezolvera 16 Vikoristannya odnogo chi kilkoh rezolveriv mozhe zbilshiti zhittyezdatnist identifikatora resursu cherez te sho vin ne vkazuye napryamu na fizichne roztashuvannya resursu yake mozhe zminitis Ostannoyu formoyu konektora ye tunel yakij prosto provodit zapiti cherez mezhu sistemi napriklad cherez fayervol Prichinoyu cherez yaku tuneli vklyucheno do arhitekturi REST a ne zakrito abstrakciyeyu merezhi ye te sho pevni komponenti mozhut peretvoryuvatis na tuneli za zapitom Napriklad tunel HTTP en aktivuyetsya pri otrimanni zapitu z metodom CONNECT Komponenti Redaguvati Cej rozdil potrebuye dopovnennya lyutij 2017 Semantika protokolu HTTP RedaguvatiTipove vikoristannya HTTP metodiv HTTP metodi URL GET PUT PATCH POST DELETEKolekciya https api example com resources Povertaye URI ta mozhlivo inshi detali resursiv kolekciyi Zaminyuye odnu kolekciyu inshoyu Zazvichaj ne vikoristovuyut Stvoryuye novij resurs v kolekciyi URI dlya novogo resursu zastosunok priznachaye avtomatichno ta zazvichaj povertaye u vidpovidi 17 Vidalyaye vsyu kolekciyu Resurs https api example com resources item17 Povertaye predstavlennya resursu kolekciyi Zaminyuye pevnij resurs kolekciyi i yaksho vin ne isnuye stvoryuye jogo Onovlyuye pevnij resurs kolekciyi Zazvichaj ne vikoristovuyut Vidalyaye pevnij resurs kolekciyi Hocha resurs mozhe buti yakim zavgodno diyi yaki mozhna vikonuvati nad resursom viznachayutsya povidomlennyami yaki viznacheno standartnim protokolom V sistemi WWW cej protokol HTTP ale isnuyut REST arhitekturi na osnovi j inshih protokoliv Standart HTTP viznachaye 8 tipiv povidomlen Najchastishe vikoristovuyut 4 z nih GET otrimati predstavlennya resursu DELETE znishiti resurs POST stvoriti novij resurs na misci danogo vikoristavshi peredane predstavlennya PUT zaminiti stan potochnogo resursu stanom sho opisuyetsya peredanim predstavlennyamCi vikoristovuyutsya shob dosliditi API HEAD otrimati zagolovki yaki b vidsilalis razom z predstavlennyam cogo resursu ale ne same predstavlennya OPTIONS viznachiti spisok metodiv na yaki cej resurs vidpovidaye Inshi dva metodi CONNECT ta TRACE vikoristovuyutsya lishe dlya HTTP proksi 18 Isnuye takozh dev yatij metod shopravda opisanij ne v HTTP a v dodatku RFC 5789 PATCH zminiti lishe chastinu cogo resursu na osnovi danogo predstavlennya Yaksho yakas chastina resursu ne zgaduyetsya v peredanomu predstavlenni ne chipati yiyi Ce znizhuye kilkist informaciyi yaku potribno peredavati She dva metodi opisuyutsya v propoziciyi do standartu Internet Draft snell link method LINK priv yazati pevnij resurs do cogo UNLINK vidv yazati resurs vid cogoMetodi GET PUT ta DELETE idempotentni sho oznachaye sho nezalezhno vid togo skilki raziv vi vikonayete operaciyu yaku voni prosyat vi otrimayete toj samij rezultat Zvisno spershu DELETE poverne 204 No Content a potim 404 Not Found ale resursu ne bude sho pislya odnogo vidalennya sho pislya desyati Idempotentnist ye duzhe vazhlivoyu v merezhi de vi ne znayete chi dosyag zapit uspihu i ne otrimavshi vidpovidi nadsilayete jogo she raz POST ne idempotentnij tobto vidpravivshi POST na stvorennya povidomlennya kilka raziv vi otrimayete kilka povidomlen 19 URI Templates en opisuyutsya v RFC 6570 i viglyadayut tak 20 https uk wikipedia org w index php search search Div takozh RedaguvatiOpenAPI SpecificationPrimitki Redaguvati a b Fielding 2000 s 76 Fielding 2000 s 78 Fielding 2000 s 79 Fielding 2000 s 80 Fielding 2000 s 81 Fielding 2000 s 82 Fielding 2000 s 84 Fielding 2000 s 85 a b Fielding 2000 s 88 Fielding 2000 s 89 a b Fielding 2000 s 90 Arhivovana kopiya Arhiv originalu za 27 grudnya 2016 Procitovano 14 lyutogo 2017 RFC7231 section 7 1 4 Arhiv originalu za 25 travnya 2017 Procitovano 14 lyutogo 2017 Fielding 2000 s 92 Fielding 2000 s 94 a b Fielding 2000 s 95 Pomilka cituvannya Nepravilnij viklik tegu lt ref gt dlya vinosok pid nazvoyu thereisnorightway ne vkazano tekst Richardson Amundsen ta Ruby 2013 s 33 Richardson Amundsen ta Ruby 2013 s 36 Richardson Amundsen ta Ruby 2013 s 49 Literatura RedaguvatiFielding Roy 2000 Architectural Styles and the Design of Network based Software Architectures Ph D anglijskoyu Kalifornijskij universitet v Irvajni Arhiv originalu za 15 travnya 2012 Procitovano 20 lyutogo 2009 Richardson Leonard Amundsen Mike Ruby Sam 2013 RESTful Web APIs vid First edition O Reilly ISBN 978 1 4493 5806 8 Procitovano 13 veresnya 2017 Posilannya RedaguvatiMichael S Mikowski 10 serpnya 2015 RESTful APIs the big lie Arhiv originalu za 7 listopada 2017 Procitovano 22 lyutogo 2018 Cesare Pautasso Olaf Zimmerman Frank Leymann RESTful Web Services vs Big Web Services Making the Right Architectural Decision anglijskoyu 17th International World Wide Web Conference WWW2008 Arhiv originalu za 15 travnya 2012 Procitovano 20 lyutogo 2009 Otrimano z https uk wikipedia org w index php title REST amp oldid 37924721