Читателей, плохо знакомых с этой темой, поразят бесконечные дискуссии о том, что вы должны делать, и относительное отсутствие уроков из опыта. Тот факт, что REST «предпочтительнее» SOAP, - это, я полагаю, высокий уровень обучения на собственном опыте, но, черт возьми, мы, должно быть, продвинулись дальше? Это 2016 год. Диссертация Роя была в 2000 году. Что мы разработали? Это было весело? Было ли легко интегрироваться с? Поддерживать? Сможет ли он справиться с ростом количества смартфонов и нестабильной мобильной связи?
По мнению ME, реальные сети ненадежны. Таймаут запросов. Подключения сброшены. Сети выходят из строя на часы или дни. Поезда идут в туннели с мобильными пользователями на борту. Для любого заданного запроса (что иногда признается во всех этих обсуждениях) запрос может упасть в воду на своем пути, или ответ может упасть в воду на обратном пути. В этих условиях отправка запросов PUT, POST и DELETE непосредственно против основных ресурсов всегда казалась мне немного грубой и наивной.
HTTP не делает ничего для обеспечения надежного завершения запроса-ответа, и это нормально, потому что это должная работа сетевых приложений. При разработке такого приложения вы можете перепрыгивать через обручи, чтобы использовать PUT вместо POST, а затем еще обводки, чтобы выдавать определенный вид ошибки на сервере, если вы обнаруживаете повторяющиеся запросы. Вернувшись к клиенту, вам нужно перепрыгнуть через обручи, чтобы интерпретировать эти ошибки, выполнить повторную выборку, повторную проверку и повторную публикацию.
Или вы можете сделать это: рассматривайте свои небезопасные запросы как эфемерные однопользовательские ресурсы (назовем их действиями). Клиенты запрашивают новое «действие» над основным ресурсом с пустым POST для ресурса. POST будет использоваться только для этого. Получив безопасный доступ к URI только что созданного действия, клиент отправляет небезопасный запрос на URI действия, не на целевой ресурс. Разрешение действия и обновление «реального» ресурса - это должная работа вашего API, и здесь она отделена от ненадежной сети.
Сервер выполняет свою работу, возвращает ответ и сохраняет его в соответствии с согласованным URI действия. Если что-то пойдет не так, клиент повторяет запрос (естественное поведение!), А если сервер уже видел его, он повторяет сохраненный ответ и больше ничего не делает.
Вы быстро заметите сходство с обещаниями: мы создаем и возвращаем заполнитель для результата, прежде чем что-либо делать. Также как и обещание, действие может быть успешным или неудачным один раз, но его результат может быть получен повторно.
Лучше всего то, что мы даем отправляющим и получающим приложениям возможность связать однозначно идентифицированное действие с уникальностью в их соответствующих средах. И мы можем начать требовать и принуждать клиентов к ответственному поведению: повторяйте свои запросы сколько угодно, но не создавайте новое действие, пока не получите окончательный результат от существующего.
Таким образом, исчезают многочисленные острые проблемы. Повторные запросы на вставку не создают дубликатов, и мы не создаем реальный ресурс, пока не получим данные. (столбцы базы данных могут оставаться непустыми). Повторные запросы на обновление не попадут в несовместимые состояния и не перезапишут последующие изменения. Клиенты могут (повторно) получать и беспрепятственно обрабатывать исходное подтверждение по любой причине (сбой клиента, отсутствие ответа и т. Д.).
Последовательные запросы на удаление могут видеть и обрабатывать исходное подтверждение, не вызывая ошибки 404. Если что-то займет больше времени, чем ожидалось, мы можем дать предварительный ответ, и у нас есть место, где клиент может проверить окончательный результат. Самая приятная часть этого узора - его свойство Кунг-Фу (Панда). Мы берем слабость, склонность клиентов повторять запрос каждый раз, когда они не понимают ответа, и превращаем его в сильную сторону :-)
Прежде чем сказать мне, что это не RESTful, пожалуйста, рассмотрите многочисленные способы соблюдения принципов REST. Клиенты не создают URL-адреса. API остается доступным для обнаружения, хотя и с небольшим изменением семантики. Глаголы HTTP используются правильно. Если вы думаете, что это огромное изменение, которое нужно реализовать, я могу сказать вам по опыту, что это не так.
Если вы думаете, что вам нужно хранить огромные объемы данных, давайте поговорим об объемах: типичное подтверждение обновления составляет доли килобайта. HTTP в настоящее время дает вам минуту или две для окончательного ответа. Даже если вы храните действия только в течение недели, у клиентов есть много шансов наверстать упущенное. Если у вас очень большие объемы, вам может потребоваться специальное хранилище значений ключей, совместимое с кислотами, или решение в памяти.
person
bbsimonbb
schedule
18.02.2016
idempotency
- это ключ. Прочтите PUT или POST: ОТДЫХ по рассказу Джона Калкота. Если ваш метод идемпотентен, используйте PUT. Если нет, используйте POST. - person LCJ   schedule 11.08.2016JavaBrains
объясняет это очень ясно. Взгляните на youtube.com/watch?v=rhTkRK53XdQ - person Ram   schedule 17.08.2018