Je ne vois aucun avantage à effectuer des tentatives du côté client uniquement si vous devez toujours impliquer l'utilisateur. Les avantages de réessayer côté serveur sont les suivants: les tentatives peuvent être effectuées plus rapidement, dans un environnement mieux contrôlé (problèmes WAN exclus), ont plus de contexte d'erreur (sachez qu'il s'agit exactement du OptimisticLockingFailureException - plus au paragraphe suivant), utiliser moins de trafic, moins d'analyse de requêtes et de construction de contexte, rendra le service plus accessible et plus simple à utiliser pour les clients, fera du bien à tous les clients possibles peut-être écrit plus tard (Android, js, iOS réécrit, etc.) être ajouté de manière transparente pour les opérations qui n'ont pas utilisé la base de données initialement, et plus ...
Cependant, si vous avez décidé de gérer le problème sur le client, je pense qu'il serait erroné de laisser le client savoir le exact cause du problème de toute façon parce que c'est un détail d'implémentation. Après tout, vous pourriez plus tard passer à une autre base de données avec des exceptions différentes. Au lieu de cela, je voudrais plaider en faveur d'un mécanisme plus général avec une sémantique appropriée, par ex. renvoyant le code HTTP 503 et définissant l'en-tête "Retry-After" (voir HTTP statuscode to retry same request). En spécifiant que vos clients API peuvent/devraient s'attendre et gérer cette combinaison (et le gérer dans le client iOS) est probablement une chose sage à faire: alors peut-être à la fois ou peut-être plus tard, vous pouvez transaprently mettre en œuvre réessayer côté serveur et arrêtez de renvoyer le code 503 lorsque OptimisticLockingFailureException arrive (et peut-être commencer à le renvoyer si, par exemple, vous voulez limiter le débit de la demande et que vos clients le gèrent déjà). Le report de cette décision et le fait de la rejouer d'une façon ou d'une autre plus tard vous donnera plus de liberté avec votre API.