Уместно ли возвращать тайм-аут шлюза HTTP 504 в качестве ответа, если время ожидания сервера базы данных истекло?

В службе REST возвращает ли соответствующий код состояния 504, когда время ожидания приложения истекает, ожидая запроса к базе данных, и не может выполнить запрос клиента?

504 Тайм-аут шлюза

Сервер действовал как шлюз или прокси-сервер и не получал своевременный ответ от вышестоящего сервера.


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


Любые указатели на то, как другие службы REST обрабатывают тайм-аут базы данных?


person gregmac    schedule 19.01.2014    source источник


Ответы (1)


Я бы также вернул 500 с подробностями в полезной нагрузке, указывающими, что пошло не так. Это описание 504 из RFC 2616:

Сервер, действуя как шлюз или прокси, не получил своевременный ответ от вышестоящего сервера, указанного URI (например, HTTP, FTP, LDAP) или какого-либо другого вспомогательного сервера (например, DNS), к которому ему необходимо было получить доступ при попытке завершить запрос.

Это описание ошибки для 504 указывает на то, что сервер действует как шлюз или прокси-сервер, чего ваша служба точно не делает.

person Mike Dunker    schedule 20.01.2014
comment
Разве технически его служба не будет действовать как прокси для сервера базы данных? Я мог видеть 504 или 503 для этого. - person crush; 15.03.2016
comment
Я бы сказал, что это только прокси, если его приложение было оболочкой API для базы данных, предоставляя такие операции API, как создание таблицы и вставка элемента. Если он использует базу данных как часть функций API, но не API базы данных, тогда база данных будет ресурсом, а API не будет прокси. - person Mike Dunker; 15.03.2016