Вимкнення VM через інтерфейс REST
Це насправді дещо відомий приклад, викладений Тімом Брей у 2009 році .
Рой Філдінг, обговорюючи проблему, поділився цим спостереженням :
Я особисто віддаю перевагу системам, які розглядають моніторинг стану (наприклад, стан живлення) як нередагований.
Коротше кажучи, у вас є один інформаційний ресурс, який повертає поточне подання стану, що контролюється; це представлення може містити посилання гіпермедіа до форми, яка вимагає зміни до цього стану, а форма має ще одне посилання на ресурс для обробки (кожного) запиту на зміну.
Сет Ладд мав ключову думку про проблему
Ми перетворили Бег від простого стану людини до справжнього Іменника, про який можна створити, оновити та поговорити.
Повернення цього до перезавантаження машин. Я заперечую, що ви POST на / vdc / 434 / cluster / 4894 / server / 4343 / перезавантажуєтесь Після публікації у вас є URI, який представляє цю перезавантаження, і ви можете отримати її для оновлення статусу. Через магію гіперпосилання представлення Перезавантаження пов'язане із Сервером, який перезавантажується.
Я думаю, що карбування простору URI дешево, а URI - навіть дешевше. Створіть колекцію видів діяльності за зразком іменників та POST, PUT та DELETE away!
RESTful програмування - це бюрократія Vogon у веб-масштабі. Як ти робиш що- небудь ВІДНОМО? Винайдіть нові документи для цього та оцифруйте документи.
Дещо вигадливішою мовою, те, що ви робите, - це визначення протоколу додатка домену для "вимкнення VM" та визначення ресурсів, які потрібно виставити / реалізувати цей протокол
Дивлячись на власні приклади
PATCH /api/virtualmachines/42
Content-Type:application/json
{ "state": "shutting down" }
Все добре; ви насправді не розглядаєте сам запит як власний окремий інформаційний ресурс, але ви все одно можете керувати.
Ви трохи пропустили своє уявлення про зміну.
Однак із PATCH додане об'єднання містить набір інструкцій, що описують, як ресурс, що перебуває в даний час на початковому сервері, повинен бути модифікований для створення нової версії.
Наприклад, формат носіїв формату JSON Patch форматує інструкції так, ніби ви безпосередньо змінювали документ JSON
[
{ "op": "replace", "path": "state", "value": "shutting down" }
]
У Вашій альтернативи ідея близька, але не очевидно правильна. PUT- це повна заміна стану ресурсу за цільовою URL-адресою , тому ви, ймовірно, не вибрали б написання, схоже на колекцію, як ціль представлення одного об'єкта.
POST /api/virtualmachines/42/actions
Відповідає вигадці про те, що ми додаємо дію до черги
PUT /api/virtualmachines/42/latestAction
Відповідає вигадці про те, що ми робимо оновлення до хвостового елемента в черзі; трохи дивно це робити так. Принцип найменшого сюрпризу рекомендує надавати кожному PUT свій унікальний ідентифікатор, а не розміщувати їх у одному місці та змінювати кілька ресурсів одночасно.
Зауважте, що, оскільки ми обговорюємо написання URI - REST не хвилює; /cc719e3a-c772-48ee-b0e6-09b4e7abbf8bє ідеально кромулентним URI, що стосується REST. Читання, як і імена змінних, є окремим питанням. Використання написань, які відповідають RFC 3986 , зробить людей набагато щасливішими.
CQRS
Що робити, якщо у нас є домен CQRS з багатьма такими "діями" (ака командами), які потенційно можуть призвести до оновлення декількох агрегатів або не можуть бути відображені в операціях CRUD на конкретних ресурсах і субресурсах?
Грег Янг на CQRS
CQRS - це дуже простий шаблон, який дає багато можливостей для архітектури, які в іншому випадку можуть не існувати. CQRS не є можливою послідовністю, він не відбувається, це не обмін повідомленнями, він не має відокремлених моделей для читання і запису, а також не використовує пошук подій.
Коли більшість людей говорять про CQRS, вони дійсно говорять про застосування шаблону CQRS до об'єкта, який представляє службову межу програми.
Зважаючи на те, що ви говорите про CQRS в контексті HTTP / REST, здається, розумно припустити, що ви працюєте в цьому останньому контексті, тому давайте продовжимо це.
Це, на диво, навіть простіше, ніж ваш попередній приклад. Причина цього проста: команди - це повідомлення .
Джим Вебер описує HTTP як протокол програми офісу 1950-х років; робота виконується за допомогою прийому повідомлень та розміщення їх у поштових скриньках. Така ж ідея - ми отримуємо чисту копію форми, заповнюємо її специфікою, яку ми знаємо, доставляємо. Та да
Чи слід намагатися моделювати стільки команд, скільки конкретних створює або оновлює конкретні ресурси, де це можливо (дотримуючись першого підходу з прикладу I) і використовувати "кінцеві точки дії" для решти?
Так, якщо "конкретними ресурсами" є повідомлення, а не сутності в доменній моделі.
Ключова ідея: ваш REST API все ще є інтерфейсом ; ви повинні мати можливість змінити базову модель, не вимагаючи від клієнтів змінити повідомлення. Коли ви випускаєте нову модель, ви випускаєте нову версію веб-кінцевих точок, які знають, як прийняти протокол домену та застосувати його до нової моделі.
Чи краще модель CQRS підходить для RPC типу API?
Не насправді - зокрема, веб-кеші - чудовий приклад "зрештою послідовної моделі читання". Зробити кожен із ваших поглядів незалежно адресованим, кожен зі своїми правилами кешування, дає вам безліч масштабів безкоштовно. Існує відносно мало апеляцій до виключно підходу RPC до читання.
Для записів це складніше питання: надіслати всі команди одному обробнику в одній кінцевій точці або одному сімейству кінцевих точок, звичайно, простіше . REST - це справді більше про те, як ви знаходите спілкування, де кінцева точка знаходиться з клієнтом.
Поводження з повідомленням як власним унікальним ресурсом має перевагу в тому, що ви можете використовувати PUT, попереджаючи посередницькі компоненти про те, що обробка повідомлення є безсилою, щоб вони могли брати участь у певних випадках помилок, приємно мати . (Зауважте: що з точки зору клієнтів, якщо ресурси мають різний URI, то це різні ресурси; той факт, що вони можуть мати однаковий код обробника запитів на сервері походження, є деталлю реалізації, прихованою уніформою інтерфейс).
Філдінг (2008)
Я також повинен зазначити, що вищевикладене ще не є повністю ВІДКРИТИм, принаймні як я використовую цей термін. Все, що я зробив, - це описані сервісні інтерфейси, які не більше ніж будь-які RPC. Для того, щоб зробити його RESTful, мені потрібно було б додати гіпертекст, щоб запровадити та визначити послугу, описати, як виконати відображення за допомогою форм та / або шаблонів посилань, та надати код для комбінування візуалізацій корисними способами.