Информация об изменениях

Сообщение Re[7]: Возврат ошибок в API от 25.06.2019 19:07

Изменено 25.06.2019 19:10 RushDevion

Re[7]: Возврат ошибок в API
НС>·>Принципиальное отличие, что возвратить 4xx клиенту — обвинить клиента в том, что он что-то делает не так. А 5xx — это что-то не так с сервером.
НС>Чем при этом должна отличаться реакция клиента?

Главным образом retry-политикой и способом обработки ошибки, e.g.
1) 500 Internal Server Error — заретраиться сразу, но не более 3-х попыток.
Т.к., возможно, ошибка либо разовая (e.g. таймаут сработал, GC невовремя запустился и т.п.), либо случилась на конкретной ноде (если у нас кластер).
Значит, есть шанс, что следующий запрос придет на другую ноду и там все будет хорошо.
Ну а если три раза подряд облом — скорей всего вся система лежит и больше от нее ничего не добьешься.
2) 503 Service Unavailable, 529 To Many Requests — мы вот-вот положим сервер своими запросами, надо бы замедлится.
Здесь подойдет бесконечный ретрай в рамках общего таймаута, с эспоненциальным ростом времени ожидания между попытками.
Т.е. первый ретрай — через 1сек., потом через 2, потом через 4 и т.д.
3) 4xx — тут ретраиться бесполезно, т.к. ответ не изменится. Остается только обработать ошибку.
400 Bad Request — можно распарсить валидационные ошибки из тела ответа и отобразить их в UI
404 Not Found — показать сообщение "Запись не найдена"
403 Forbidden — показать сообщение "Доступ запрещен", возможно записать в Audit Log
409 Conflict — показать сообщение "Ваша копия данных устарела. Обновить? Да/Нет."
Re[7]: Возврат ошибок в API
НС>·>Принципиальное отличие, что возвратить 4xx клиенту — обвинить клиента в том, что он что-то делает не так. А 5xx — это что-то не так с сервером.
НС>Чем при этом должна отличаться реакция клиента?

Главным образом retry-политикой и способом обработки ошибки, e.g.
1) 500 Internal Server Error — заретраиться сразу, но не более 3-х попыток.
Т.к., возможно, ошибка либо разовая (e.g. таймаут сработал, GC невовремя запустился и т.п.), либо случилась на конкретной ноде (если у нас кластер).
Значит, есть шанс, что следующий запрос придет на другую ноду и там все будет хорошо.
Ну а если три раза подряд облом — скорей всего вся система лежит и больше от нее ничего не добьешься.
2) 503 Service Unavailable, 529 To Many Requests — мы вот-вот положим сервер своими запросами, надо бы замедлиться.
Здесь подойдет бесконечный ретрай в рамках общего таймаута, с эспоненциальным ростом времени ожидания между попытками.
Т.е. первый ретрай — через 1сек., потом через 2, потом через 4 и т.д.
3) 4xx — тут ретраиться бесполезно, т.к. ответ не изменится. Остается только обработать ошибку.
400 Bad Request — можно распарсить валидационные ошибки из тела ответа и отобразить их в UI
404 Not Found — показать сообщение "Запись не найдена"
403 Forbidden — показать сообщение "Доступ запрещен", возможно записать в Audit Log
409 Conflict — показать сообщение "Ваша копия данных устарела. Обновить? Да/Нет."