Ответ HTTP 412 - можно ли включать содержание?
Я создаю УСПОКОИТЕЛЬНОЕ хранилище данных и усиливаю Условное выражение, ПОЛУЧАЮТ и ПОМЕЩАЮТ. Во время условного выражения ПОМЕЩАЕТ клиент, может включать Завершающий тег от предыдущего, Надевают ресурс и если текущее представление не будет соответствовать серверу, то возвратит код состояния HTTP 412 (Неудавшееся Предварительное условие). Обратите внимание, что это - основанный на Atom сервер/протокол.
Мой вопрос, когда я возвращаю 412 состояний, я могу также включать новое представление ресурса, или пользователь должен выйти, новое ДОБИРАЮТСЯ? Спецификация HTTP, кажется, не сказала да или нет, и ни один не делает спецификацию Atom (хотя их пример показывает пустое тело объекта на ответе). Кажется довольно расточительным не возвратить новое представление и заставить клиент конкретно ПОЛУЧИТЬ его. Мысли?
3 ответа
Хотя условные GET и PUT суммируются как «условные запросы» они концептуально сильно различаются. Условные GET - это оптимизация производительности, а условные PUT - это механизм управления параллелизмом. Их сложно обсуждать вместе.
На ваш вопрос относительно условного GET: если вы отправите GET и включите заголовок If-None-Match, сервер отправит 200 Ok, если ресурс изменился, и 304 Not Modified, если это не так (если условие не выполнено). 412 следует использовать только с условными PUT.
ОБНОВЛЕНИЕ: Кажется, я немного неправильно понял вопрос. К вашему сведению относительно «обновления» локальной копии при неудачном условном PUT: вполне может быть, что в кеше уже есть самая новая версия, и ваше обновление-GET будет обслуживаться из некоторого кеша. Если сервер возвращает текущий объект с помощью 412, это может привести к снижению производительности.
Если количество дополнительных запросов, возникших из-за дополнительного запроса после конфликта обновлений, достаточно велико, чтобы у вас возникли проблемы с производительностью, я бы предположил, что у вас могут быть проблемы с детализацией ваших ресурсов.
Вы действительно ожидаете, что миллионы раз в день несколько пользователей будут редактировать один и тот же ресурс одновременно? Возможно, вам нужно сохранить дельта-изменения ресурса, а не обновлять ресурс напрямую. Если действительно существует такая большая конкуренция за эти ресурсы, то разве пользователи не будут постоянно работать с устаревшими данными.
Если ваша проблема заключалась в том, что ваш ресурс содержит дату последнего изменения и последнего измененного пользователя, и вам нужно было выполнять GET после каждого PUT, я был бы более убежден в необходимости изменить правила.
Тем не менее, я думаю, что снижение производительности из-за дополнительного запроса того стоит для ясности для разработчика клиента.
Нет, строго говоря, не следует. Коды ошибок обычно указывают на то, что что-то пошло не так. Хотя ничто не помешает вам вернуть контент (и на самом деле, некоторые ошибки, такие как 404, возвращают красивую страницу, в которой говорится, что вы не нашли то, что ищете), суть ответа заключается не в том, чтобы вернуть другой контент, а чтобы вернуть что-то, что говорит вам, что было не так. Технически вы также не должны возвращать эти данные, потому что вы передали If-None-Match: etag (я предполагаю, что это то, что вы прошли?)
С другой стороны, вам действительно нужно оптимизировать один дополнительный HTTP-вызов?
Чем больше я думаю об этом, тем больше убеждаюсь, что это плохая идея. Собираетесь ли вы возвращать контент при любых других ошибках? Семантика PUT - это PUT. Для GET следует использовать семантику GET.