Чи є проблеми із впровадженням спеціальних методів HTTP?

У нас є URL-адреса в наступному форматі

/ instance / {instanceType} / {instanceId}

Ви можете викликати його за допомогою стандартних методів HTTP: POST, GET, DELETE, PUT. Однак ми вживаємо ще декілька дій, таких як "Зберегти як чернетка" або "Curate"

Ми думали, що ми можемо просто використовувати спеціальні методи HTTP, такі як: ПРОЕКТ, ВАЛІДАТ, КУРАТ

Я думаю, що це прийнятно, оскільки кажуть стандарти

"Набір загальних методів для HTTP / 1.1 визначено нижче. Хоча цей набір може бути розширений, додаткові методи не можна вважати спільними для тієї самої семантики для окремо розширених клієнтів та серверів."

І такі інструменти, як WebDav, створюють деякі власні розширення.

Чи є проблеми, у кого хтось зіткнувся зі спеціальними методами? Я думаю про проксі-сервери та брандмауери, але будь-які інші проблемні сфери вітаються. Чи варто залишатись у безпечній стороні і просто мати такий параметр URL-адреси, як action = валідація | curate | проект?

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

Уніфікований інтерфейс:

• простіше.
• розв'язує реалізацію від наданих ними послуг.
• дозволяє багатошарову архітектуру, включаючи такі речі, як балансири завантаження HTTP (nginx) та кеші (лак).

З іншого боку, єдиний інтерфейс:

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

Компроміси "розроблені для загальної справи в Інтернеті" і дозволили побудувати велику екосистему, яка забезпечує вирішення багатьох поширених проблем веб-архітектури. Дотримання єдиного інтерфейсу дозволить вашій системі скористатися цією екосистемою, порушуючи її, це ускладнить. Можливо, ви хочете використовувати балансир навантаження, наприклад nginx, але тепер ви можете використовувати лише балансир навантаження, який розуміє "ПРОЕКТ" та "СТРУКТУВАННЯ". Ви можете використовувати шар кешу HTTP, як Varnish, але тепер ви можете використовувати лише кеш-шар HTTP, який розуміє DRAFT і CURATE. Ви можете попросити когось про допомогу щодо усунення несправностей сервера, але ніхто більше не знає семантику CURATE-запиту. Можливо, буде важко змінити бажаний бібліотека клієнтів чи серверів, щоб зрозуміти та правильно реалізувати нові методи. І так далі.

Правильний спосіб ^* представити це як перетворення стану на ресурсі (або пов'язаних з ним ресурсах). Ви не розробляєте публікацію, перетворюєте її draftстан trueабо створюєте draftресурс, який містить зміни та посилання на попередні версії проекту. Ви не ТЕКУЮТЬ публікацію, ви перетворюєте її curatedстан на trueабо створюєте curationресурс, який пов'язує публікацію з користувачем, який її створив .

^{* Правильно в тому, що він найбільш дотримується архітектурних принципів REST.}

Я вважаю за краще створити їх як підресурси, на які ви виконуєте запит POST.

Вважайте, що у вас є ресурс /instance/type/1, я б представив, що цей ресурс передає пару посилань на "дії", які можна виконати на ресурсі, наприклад, /instance/type/1/draftта /instance/type/1/curate. У JSON це може бути так просто, як:

{
    "some property":"the usual value",
    "state": "we can still inform the client about the current state",
    "draft": "http://server/instance/type/1/draft",
    "curate": "http://server/instance/type/1/curate"
}

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

Підхід до «наївного» підходу переміщення між можливими станами на ресурсі має недолік не фіксувати, які події призвели до цих переходів.

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

Я думаю, що власний метод HTTP - це найкращий спосіб реалізувати дії сутності. Додавання дії до тіла сутності (POST) не здається правильним, воно не є частиною вашої сутності (хоча результат може бути збережений у ньому). Також, використовуючи власні методи HTTP, проксі-сервери можуть визначати їх дії без необхідності аналізу тіла об'єкта.

Це як CRUD, ви завжди хочете їх реалізувати, але також маєте свій власний набір дій (за суттю). Я дійсно не бачу, у чому б була проблема їх розширення.

Також @Rein Henrichs "Ви не створюєте посаду, перетворюєте її стан проекту в істинне або створюєте проект ресурсу", мені здається помилковим. draftsВластивість буде використовуватися для постійного збереження стану, а не для створення перетворення. Дії навіть не обов'язково призводять до "стану" або зберігаються у властивості. Створення окремої сутності для кожного стану / перетворення здається ще більш нечітким .. намагайтеся підтримувати ту саму посилання (URI) на сутність.