Є REST та HATEOAS хорошою архітектурою для веб-сервісів?

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

Веб-сервіси REST були створені шляхом застосування архітектури REST до API. Але чи є насправді підстави вважати REST бажаною архітектурою для цього домену? Більш конкретно, чи є докази того, що HATEOAS є вигідним принципом проектування для зв'язку між машиною?

Мене хвилює те, що HATEOAS має сенс для гіпермедіа, оскільки існує декілька відомих типів вмісту (HTML, зображення, відео тощо), і клієнт знає, як їх споживати. Але для API типи вмісту дуже специфічні, і їх може споживати змістовно лише клієнт, якщо клієнт спеціально запрограмований для їх споживання. Повернення URL-адреси клієнту саме по собі не дає клієнту можливість споживати вказаний ресурс.

AFAIK Філдінг не стверджував, що REST не є корисним, він просто описував фактичну архітектуру Інтернету.

Я б подумав, що це трохи продає це. Зрештою, REST - це перелік архітектурного стилю, який Філдінг використовував як головний архітектор специфікації HTTP / 1.1 .

Але чи є насправді підстави вважати REST бажаною архітектурою для цього домену? Чи є докази, які говорять про те, що HATEOAS є вигідним принципом проектування для зв'язку між машиною і машиною?

"Це залежить". HATEOAS є частиною єдиного обмеження інтерфейсу REST.

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

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

Це просто працює .

Це, звичайно, не універсально. Філдінг у 2008 році написав:

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

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

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

schema.org - одна з частин зусиль для створення машиночитаного словника; машинні агенти використовують клієнта, щоб знайти смислові підказки, і застосовує власне розуміння сенсу, щоб вибрати правильні дії, які слід вжити.

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

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

Ні, "повний відпочинок" не настільки великий.

Як свідчить відсутність людей, які впроваджують HATEOS у своїх API та нескінченні аргументи, над якими дієслово HTTP використовувати для певного виклику.

Але ви повинні визнати, чому REST настільки популярний. До його прийняття існували різні шалено складні протоколи, такі як ebXML та SOAP, що включають підтвердження, тайм-аути, ідентифікатори розмов та стан.

Підвищити ці речі і потім пояснити їх споживачам api було важким завданням. "чому я просто не зроблю GET з ідентифікатором, який я хочу в рядку запиту, і ви надсилаєте мені дані?" було очевидним і поширеним питанням.

Тоді другою проблемою був XML, JavaScript не зрозумів цього, схеми були болем у попці, і ви отримали б величезні файли txt, здебільшого складаються з <MyLongObjectName>. Тож люди замість цього почали використовувати JSON.

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

Зазначимо, що Рой не був оригінальним винахідником більшості принципів REST, він об'єднує багато принципів, які, як відомо, працюють у попередніх системах для вирішення різних конкретних проблем. REST - це просто природний висновок застосування цих принципів в єдиній архітектурі.

Ще до того, як Рой Філдінг написав дисертацію про REST , HTTP вже був розроблений на основі принципів, які згодом стають відомими як REST. На закінчення своєї дисертації він написав:

На початку наших зусиль в рамках Інженерної робочої групи з Інтернету для визначення існуючого протоколу передачі гіпертексту (HTTP / 1.0) [19] та розробки розширень для нових стандартів HTTP / 1.1 [42] та Уніфікованих ідентифікаторів ресурсів (URI) [21] ], Я визнав необхідність моделі того, як повинна працювати всесвітня павутина. Ця ідеалізована модель взаємодій у рамках загальної веб-програми, що називається архітектурним стилем Представницького державного перенесення (REST), стала основою сучасної веб-архітектури, забезпечуючи керівні принципи, за допомогою яких можна було б визначити недоліки в існуючій архітектурі та розширення перевірені до розгортання .

REST і HATEOS добре підходять для проблеми, для якої він був розроблений:

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

Однак слід зазначити, що Інтернет та REST не обов'язково підходять для всіх проблем:

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

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

Є багато API, які дійсно не відповідають REST. API, які не потребують такого масштабування, який REST розроблений для вирішення, не споживаються багатьма організаціями, які можуть розвиватися незалежно, і не потребують довготривалості; для цих проблем обмеження REST - це просто жакет.

Але чи є насправді підстави вважати REST бажаною архітектурою для цього домену? Більш конкретно, чи є докази того, що HATEOAS є вигідним принципом проектування для зв'язку між машиною?

Свідченням є успіх Інтернету у вирішенні проблем багатьох людей. REST - це гібридна архітектура, яка поєднує в собі проекти багатьох попередніх архітектурних стилів. Багато проблемних доменів не мають усіх вимог Інтернету, і вони не повинні виконувати всі обмеження REST, щоб добре працювати. Ось чому існує багато успішних архітектур, які чудово працюють, просто застосовуючи деякі частини REST, а не інші. Наприклад, HATEOAS та Uniform Interface - це принципи, які часто пропускаються API, яким не потрібно перетинати організаційні межі та системи, що мають відносно короткий термін амортизації.

У презентації Fielding про Adobe Experience Manager:

REST НЕ архітектура!

Відпочинок - це архітектурний стиль, який є абстрагуванням різної архітектури, що існує в Інтернеті.

REST - це накопичення дизайнерських обмежень для спонукання архітектурних властивостей

REST - це модна мова, і всі хочуть мати API RESTful. Насправді, коли люди стикалися з обмеженнями REST, вони скасували деякі з цих обмежень, оскільки не було потреби або жодної вигоди, щоб застосувати всі ці обмеження.

Як ви вже згадували, HATEOAS корисний, коли клієнтом є веб-браузер. Коли клієнт мобільний додаток, можливо, не так вже й багато. Це було б хорошою практикою, але є також витрати, пов’язані з дизайном такого додатка, настільки, що, на приклад, команда мобільних додатків та команда заднього кінця просто погодилися відмовитися від цього обмеження. І такий сенс має сенс, оскільки обидві команди не так сильно поєднані, бо працюють в одній компанії.

Відпочинок в АЕМ

якщо ви хочете створити службу, яку споживає інший сервер, то xmlrpc - правильний вибір. Якщо ви хочете - це послуга, яку споживають тонкі клієнти або пристрої малої потужності .. або невідомі клієнти у відкритому Інтернеті, можливо, подумайте про відпочинок за допомогою json. Але пам’ятайте, json є неповноцінним позначенням для визначення загальних даних у порівнянні з xml.