Протокол фиксации

Question

Я создаю веб-сервис REST, который получает запрос и должен возвращать «ОК», если операция была выполнена правильно.Как я мог справиться с возможностью разрыва соединения при возврате этого сообщения «ОК»?

Например, такая система, как Amazon SimpleDB.

1) Получает запрос.2) Обработать запрос (сохранить и воспроизвести содержимое).3) Вернуть подтверждающее сообщение.

Если соединение было потеряно между фазами 2 и 3, клиент считает, что операция не была успешной, а затем отправляет снова.

Answer 1

В случае сценария тайм-аута вы можете сделать следующее:

Отправка сгенерированного клиентом уникального идентификатора с начальным запросом в заголовке.

Если клиент не получает ответ, он может отправить запрос с тем же идентификатором.

Сервер может хранить список успешно обработанных идентификаторов и возвращать OK, а не повторять действие.

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

Answer 2

Зависит от типа веб-сервиса.Вся природа HTTP и REST заключается в том, что они в основном не сохраняют состояния.

Например, в случае SimpleDB, если вы просто запрашиваете значение для данного ключа.Если в процессе его возврата клиентское соединение будет разорвано, клиент может просто повторно запросить данные позднее.Эти данные, вероятно, в любом случае были кэшированы механизмом БД или дисковым кешем операционной системы.

Если вы храните или обновляете значение, а данные идентичны, то довольно часто ядра СУБД знают, что данные отсутствуют.не изменились и поэтому обновление не займет очень много времени.

Даже сложные запросы могут выполняться быстрее во второй раз на некоторых механизмах баз данных.

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

Answer 3

Система, которую я рассмотрел ранее в этом году, имела процесс, подобный этому. Решение, которое они реализовали, состояло в том, чтобы клиент ответил на сообщение о фиксации и в этот момент снял флажок с записи. Был периодический процесс, который проверял каждые N минут, и если существовала запись, которая была завершена, но клиент не подтвердил, эта транзакция была отменена. Это позволило клиенту повторно опубликовать транзакцию, но не иметь двух «настоящих» записей, зафиксированных на стороне сервера.