REST для мягкого удаления и восстановления мягко удаленных ресурсов ограничен

Это не столько технический вопрос, сколько размышление о предмете.

REST продемонстрировал хороший способ обслуживания ресурсов с использованием HTTP-протоколов и позволил developper сделать самый чистый проект, разделив ресурсы и пользовательский интерфейс (теперь серверная часть действительно имеет дело с серверной частью только с использованием API REST).

Что касается этих API, большую часть времени мы используем GET, PUT/PATCH (хммм?), POST и DELETE, которые имитируют базу данных CRUD.

Но с течением времени, потраченного на наши проекты, мы чувствуем, что UX можно улучшить, добавив массу замечательных функций. Например, почему пользователь должен бояться удаления ресурса? Почему бы просто не поставить систему восстановления (как мы видим в приложении Google Keep, которое позволяет нам отменить удаление, которое, на мой взгляд, прекрасно с точки зрения UX).

Одним из способов предотвращения непреднамеренного удаления является использование в таблице столбца, представляющего ресурс. Например, я собираюсь удалить книгу, поэтому, нажав кнопку "Удалить", я буду отмечать эту строку только как "удалено = ИСТИНА" в моей базе данных и не отображать строки, которые удаляются при просмотре списка ресурсов (GET).,

Это последнее вступает в конфликт с нашим дорогим и любимым шаблоном REST, так как нет различий между "методами" DELETE и DESTROY.

Я имею в виду, должны ли мы думать о том, чтобы сделать REST развивающимся в соответствии с нашими потребностями в UX, под этим я подразумеваю также развитие HTTP-протоколов или это должно остаться пуристическим управлением ресурсами, и мы должны вместо этого следовать протоколу HTTP, не пытаясь его беспокоить и просто адаптироваться к нему, используя обходной путь (например, используя PATCH для мягкого удаления)?

Персонально Я хотел бы увидеть как минимум 4 новых протокола, поскольку мы пытаемся квалифицировать ресурс как можно лучше:

  • DELETE становится способом предотвращения влияния других методов на него
  • УНИЧТОЖЕНИЕ становится более драматичным, полностью удаляя следы этого ресурса
  • RECOVER - это способ сказать другим методам: "Эй, ребята, он возвращается, следите за обновлениями"
  • TRASH похож на GET, но только для удаленных ресурсов

Что заставило меня задуматься об этом, так это мое исследование чистого решения REST для решения этой проблемы с ресурсами. Я видел некоторые посты на сайте, включая

Это совет нам использовать PUT или PATCH, чтобы сделать мягкое удаление чем-то полезным, но я чувствую, что это звучит неправильно, не так ли?

Мои мысли об этой проблеме:

  • Есть ли большой шаг между предложением новых методов HTTP и обновлением предыдущих методов (я слышал, HTTP/2 - вещь, может быть, мы могли бы отправить их туда?)
  • Имеет ли это смысл за пределами сферы веб-разработки? Я имею в виду, могут ли эти изменения повлиять на другие домены, которые наши?
Источник

1 ответ

Решение

Я не уверен, что это имеет смысл даже в сфере веб-разработки; исходные условия кажутся неправильными.

RFC 7231 предлагает это объяснение для POST

Метод POST запрашивает, чтобы целевой ресурс обработал представление, заключенное в запросе, в соответствии с собственной определенной семантикой ресурса.

Загадка: если это официальное определение POST, зачем нам GET? Все, что может сделать цель с помощью GET, также может быть сделано с помощью POST.

Ответ заключается в том, что дополнительные ограничения на GET позволяют участникам принимать разумные решения, используя только информацию, включенную в сообщение.

Например, поскольку данные заголовка информируют промежуточный компонент о том, что метод является GET, посредник знает, что действие при получении сообщения является безопасным, поэтому, если ответ потерян, сообщение может быть повторено.

Само понятие сканирования в Интернете зависит от того, что вы можете переходить по любым безопасным ссылкам, чтобы открывать новые ресурсы.

Браузер может предварительно извлекать представления, потому что информация, закодированная в ссылке, сообщает ему, что сообщение для этого безопасно.

Джим Уэббер описывает это так: "HTTP - это приложение, но это не ваше приложение". Спецификация HTTP определяет семантику сообщений, так что универсальный клиент может быть понят универсальным сервером.

Использовать ваш пример; потребитель API может заботиться о различии между удалением и уничтожением, но браузер этого не делает; браузер просто хочет знать, какое сообщение отправить, что такое правила повтора, что такое правила кэширования, как реагировать на различные ошибки и т. д.

В этом сила REST - вы можете использовать любой браузер, который понимает медиа-типы представлений, и получать правильное поведение, даже если браузер полностью не знает семантику приложения.

Браузер не знает, что он общается с доской объявлений в Интернете или с панелью управления маршрутизатора.

Итак, ваша идея выглядит так, как будто вы пытаетесь достичь более богатой семантики приложения, изменяя семантику обмена сообщениями; что нарушает разделение интересов.

Источник
Другие вопросы по тегам