Наскільки корисний / важливий REST HATEOAS (рівень 3 зрілості)?

Я беру участь у проекті, де деякі старші члени команди вважають, що API REST повинен відповідати HATEOAS та реалізовувати всі рівні зрілості Річардсона ( http://martinfowler.com/articles/richardsonMatmatureModel.html )!

Більшість реалізацій AFAIK не відповідають HATEOAS, і це має бути вагома причина, чому більшість людей не роблять цього. Я можу придумати такі причини, як додаткова складність, відсутність фреймворків (сторони сервера та клієнта), стурбованість роботою та ...

Що ти думаєш? Чи мали ви досвід роботи з HATEOAS в реальному проекті світу?

Ніхто з громади REST не каже, що REST - це легко. HATEOAS - лише один із аспектів, який створює труднощі архітектурі REST.

Люди не роблять HATEOAS з усіх запропонованих вами причин: важко. Це додає складності як стороні сервера, так і клієнту (якщо ви насправді хочете отримати вигоду від цього).

ЗАРАЗ, мільярди людей сьогодні відчувають переваги REST. Чи знаєте ви, що таке "касова" URL-адреса в Amazon? Я не. Але я можу оформити замовлення щодня. Чи змінилася ця URL-адреса? Я не знаю, мені все одно.

Чи знаєте ви, що це хвилює? Кожен, хто написав екран, вискоблював автоматизований клієнт Amazon. Хтось, ймовірно, кропітко нюхав веб-трафік, читав HTML-сторінки тощо, щоб знайти, які посилання дзвонити, коли і з якими корисними навантаженнями.

І як тільки Amazon змінив свої внутрішні процеси та структуру URL-адрес, ці жорстко кодовані клієнти не змогли - через те, що посилання порвалися.

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

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

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

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

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

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

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

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

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

Більшість REST не вдається "кулі" вам це не знадобиться ". Поки, звичайно, не зробите.

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

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

Так, у мене був досвід роботи з гіпермедіа в API. Ось деякі переваги:

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

2. Вбудована документація: Використання URL-адрес як зв'язкових зв'язків може вказувати розробникам клієнтів на документацію.

3. Проста логіка клієнта: Клієнт, який просто слідує за URL-адресами, а не створювати їх сам, повинен бути простішим у реалізації та підтримці.

4. Сервер приймає право власності на URL-структури: Використання гіпермедіа видаляє чітко зашифровані знання клієнта про структури URL-адрес, які використовується сервером.

5. Вимкнення завантаження вмісту для інших сервісів: Hypermedia необхідна при завантаженні вмісту на інші сервери (наприклад, CDN).

6. Версія з посиланнями: Hypermedia допомагає версії API.

7. Кілька реалізацій однієї послуги / API: Hypermedia - це необхідність, коли існує кілька реалізацій одного сервісу / API. Наприклад, сервісом може бути API для блогу з ресурсами для додавання дописів та коментарів. Якщо послуга вказана у відношенні зв’язків замість жорстко кодованих URL-адрес, то одна і та ж послуга може бути ініційована кілька разів за різними URL-адресами, розміщеними різними компаніями, але все ще доступними через один і той же чітко визначений набір посилань одним клієнтом.

Ви можете знайти глибше пояснення цих пунктів тут: http://soabits.blogspot.no/2013/12/selling-benefits-of-hypermedia.html

(є подібне запитання тут: /software/149124/what-is-the-benefit-of-hypermedia-hateoas, де я дав те саме пояснення)

Зрілість Річардсона 3 рівень цінний і його слід прийняти. Йорн Уайлдт вже узагальнив деякі переваги, а інша відповідь, Wilt, дуже добре доповнює його.

Однак рівень зрілості Річардсона 3 не такий, як HATEOAS Філдінга. Рівень зрілості Річардсона 3 стосується лише дизайну API. HATEOAS Fielding теж стосується дизайну API, але також прописує, що клієнтське програмне забезпечення не повинно вважати, що ресурс має конкретну структуру поза структурою, визначеною типом медіа. Для цього потрібен дуже загальний клієнт, наприклад веб-браузер, який не має знань про конкретні веб-сайти. Оскільки Рой Філдінг ввів термін REST і встановив HATEOAS як вимогу дотримання REST, виникає питання: чи хочемо ми прийняти HATEOAS і якщо ні, чи можемо ми все ще називати наш API RESTful чи ні? Я думаю, що ми можемо. Дозволь пояснити.

Припустимо, ми домоглися HATEOAS. Зараз клієнтська програма цього додатка є дуже загальною, але, швидше за все, користувацький досвід поганий, оскільки без будь-яких знань про семантику ресурсів представлення ресурсів не може бути налаштоване для відображення цієї семантики. Якщо ресурс 'машина' та ресурс 'будинок' мають однаковий тип медіа (наприклад, application / json), вони будуть представлені користувачеві аналогічно, наприклад, як таблиця властивостей (пари ім'я / значення).

Але гаразд, наш API справді РЕАЛЬНИЙ.

Тепер, припустимо, ми будуємо другу клієнтську програму поверх цього API. Цей другий клієнт порушує ідеї HATEOAS і має жорстку інформацію про ресурси. Він відображає машину та будинок по-різному.

Чи може API все ще називатися RESTful? Я думаю так. Не виною API є те, що один із його клієнтів порушив HATEOAS.

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

Я включив розділ HATEOAS до моєї схеми реалізації REST під назвою JAREST .

Ми будуємо API REST рівня 3, де наша відповідь знаходиться в HAL-Json. HATEOAS чудово підходить як для переднього, так і для зворотного боку, але він постає перед проблемами. Ми зробили кілька налаштувань / доповнень для управління ACL всередині відповіді HAL-Json (що не порушує стандарт HAL-Json).

Найбільші переваги HATEOAS, які я бачу, - це те, що нам не потрібно писати / вгадувати будь-які URL-адреси на нашому додатковому додатку. Все, що вам потрібно, це точка входу ( https://hostname), і звідти ви можете просто переглядати свій ресурс, використовуючи посилання або шаблонні посилання, надані всередині відповіді. Як і з цією версією, можна легко впоратися, перейменуючи / замінивши URL-адреси, розширивши ресурси додатковими зв'язками, не порушуючи фронтальний код.

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

Ще одна перевага використання HAL-Json полягає в тому, що зрозуміло, як повинна виглядати модель відповіді, оскільки існує документально підтверджений стандарт, якого слід дотримуватися.

Один з наших налаштувань є те , що ми додали дії об'єкта всередині об'єкта власної лінії зв'язку , який виставляє на передньому кінці , які дії або операції CRUD аутентіфіцированний користувач може виконувати на відповідному ресурсі ( create:POST, read:GET, update:PUT, edit:PATCH, delete:DELETE). Як і це, наш ACL на передньому кінці повністю диктується нашою реакцією API REST, повністю перекладаючи цю відповідальність на задню модель.

Отож, щоб навести короткий приклад, у HAL-Json може з’явитися об'єкт поштового зв’язку, який виглядає приблизно так:

{
    "_links": {
        "self": {
            "href": "https://hostname/api/v1/posts/1",
            "actions": {
                "read": "GET",
                "update": "PUT",
                "delete": "DELETE"
            }
        }
    },
    "_embedded": {
        "owner": {
            "id": 1,
            "name": "John Doe",
            "email": "john.doe@example.com",
            "_links": {
                "self": {
                    "href": "https://hostname/api/v1/users/1",
                    "actions": {
                        "read": "GET"
                    }
                }
            }
        }
    },
    "subject": "Post subject",
    "body": "Post message body"
}

Тепер все , що ми повинні зробити на передньому кінці , це побудувати AclServiceз isAllowedметодом , який перевіряє , є чи дію , яке ми хочемо виконати в діях об'єкта.

В даний час на передній частині це виглядає так просто, як: post.isAllowed('delete');

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

У нашому випадку ми маємо перевагу в тому, що ми будуємо і передню, і задню частину, але в принципі це НЕ повинно змінювати значення. Але загальною проблемою, яку я бачив у нашій команді, є те, що деякі розробники намагаються вирішити проблеми (архітектуру), змінюючи свою модель "бек-енд", щоб вона "відповідала" переднім потребам.

Я використовував HATEOAS в деяких реальних проектах, але з іншою інтерпретацією, ніж Річардсон. Якщо цього хочуть ваші начальники, то, мабуть, ви просто повинні це зробити. Я вважаю, що HATEOAS означає, що ваші ресурси повинні включати в себе HTML-тип, гіперпосилання на споріднені ресурси та форми HTML для викриття функціональності для інших дієслів, ніж GET. (Це коли тип Accept є text / html - інші типи вмісту не потребують цих додаткових даних.) Я не знаю, звідки походить віра, що всі REST-ресурси у всій вашій програмі повинні бути склеєні. Мережева програма повинна містити кілька ресурсів, які можуть бути, а можуть і не бути безпосередньо пов'язаними. Або чому вважається, що XML, JSON та інші типи потребують цього. (HATEOAS - специфічний для HTML.)