REST API Как обновить данные на стороне клиента после отправки запроса в бэкэнд

Question

Интерфейс / клиент показывает список элементов.Сделайте запрос к бэкэнду / API, чтобы изменить некоторые элементы.Например, добавить элемент или удалить его.Как отразить эти изменения на стороне клиента после того, как бэкэнд успешно обработал этот запрос?

Примеры:

• POST-запрос к бэкэнду, который добавляет новый элемент всписок.Тело ответа содержит добавленный элемент.Http Код состояния 201 CREATED

• УДАЛИТЬ запрос к бэкэнду, который удалил элемент из списка.Тело ответа не содержит ничего.Http Код состояния 204 НЕТ КОНТЕНТА

Решения?

1. После того, как запрос был успешно обработан (клиент получает код состояния 2xx), полный списоксобираюсь получить снова из бэкэнда.Недостаток: это означает, что у нас есть два запроса.Сначала POST, затем GET.

2. Возвращает полный список в теле ответа на запрос POST.Это кажется странным, потому что то, как клиент использует API, влияет на поведение API.

3. Клиент обрабатывает добавление или удаление самого элемента после того, как он получил 2xx от бэкэнда,Pro: только один запрос.Недостаток: проблема, если над данными работают несколько пользователей.Как обеспечить синхронизацию всего?

Существует ли общая схема того, как с этим справляться в отношении чистого дизайна API?Я заметил, что многие инструменты делают только один запрос, если вы меняете данные.Подумайте о Трелло или о чем-то подобном.

Answer 1

Как синхронизировать все?

В REST вы этого не делаете.Каждый клиент (потенциально) имеет свой собственный локальный кеш.Сервер включает стандартизированные метаданные кэширования в своих ответах, чтобы предоставить клиентам подсказку о том, как часто информация может изменяться.

Аннулирование кэша стандартизировано, но толькокеши, через которые проходит HTTP-запрос, будут видеть инициирующие запросы.Поэтому, если ваши клиенты не используют общий кеш (маловероятно, что в мире HTTPS), у кого-то будут устаревшие данные.

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

Как отразить эти изменения на стороне клиента после того, как серверная часть успешно обработала этот запрос?

Существует раздел спецификации HTTP, который описывает, как идентифицировать представление в сообщении HTTP.Он включает в себя этот отрывок

Если ответ имеет поле заголовка Content-Location и его значение поля является ссылкой на тот же URI, что и эффективный URI запроса, полезная нагрузка является представлением идентифицированного ресурсапо действующему URI запроса.

Итак, POST /foo PUT /foo PATCH /foo имеют стандартизированный способ объявления о том, что представление, заключенное в ответ, является новым представлением /foo

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

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

Интерфейс REST спроектирован так, чтобы быть эффективным для передачи крупномасштабных гипермедиа-данных, оптимизируя его для общего случая Интернета, но в результате получая интерфейс, который не является оптимальным для других форм архитектурного взаимодействия.- Филдинг, 2000