Какова правильная терминология для парадигм обработки ошибок клиентского приложения веб-службы?

Question

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

Допустим, наше приложение похоже на iTunes, но работает онлайн. Пользователь запускает клиент на основе JavaScript, который взаимодействует с веб-сервисом через AJAX. Пользователь может создавать «альбомы», а затем помещать в них «песни». На уровне API это представлено одним вызовом API для создания нового альбома, а затем одним или несколькими вызовами, чтобы связать существующую песню с новым альбомом.

Теперь традиционный клиент может приостановить все приложение, пока не подтвердит, что альбом создан. Чтобы сделать клиент snappier, мы можем с оптимизмом предполагать, что вызов API создания альбома будет успешным, и немедленно отобразить новый альбом в списке пользователя. Пользователь может начать перетаскивать песни в новый альбом, даже если вызов API для его создания все еще находится за сценой. API догонит, когда доберется туда.

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

Как называется такая стратегия? Какая хорошая литература на эту тему? Интернет-ссылки?

Answer 1

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

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

Если вы хотите, чтобы ваш клиент был более быстрым: зачем вы хотите в любом случае выполнить вызов «новый альбом»? Если вы управляете обновлениями альбома в клиенте, вам не нужно создавать альбом перед отправкой содержимого альбома.

Хороший API для такого клиента - это нечто иное, чем API "на сервере". Возможно, это поможет вам взглянуть на модель «единицы работы» Фаулера. Это для баз данных, но, на мой взгляд, идея также применима к вашим настройкам.