Как вы обрабатываете 404 ошибки, отправленные контейнером, а не приложением - PullRequest
Новая
       19

Как вы обрабатываете 404 ошибки, отправленные контейнером, а не приложением

0 голосов
/ 13 октября 2018

Предположим, что следующий ресурс REST 

https://api.service.com/jobs/{id}

Мое приложение для отдыха jboss / wildfly отправит 404 (без данных тела), если данные задания недоступны. 200 и 404 - ожидаемые коды ответов.

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

К сожалению, потребитель также получает код 404, если приложение не развернуто .Например, из-за ошибки развертывания.Этот код ответа отправляется контейнером jboss / wildfly.В этот момент потребитель неправильно интерпретирует ответ.

Так как бы вы справились с такой единственной ситуацией?Я считаю, что контейнер никогда не должен отправлять такой ответ, так как это задача приложения.

Наиболее очевидным решением могут быть некоторые данные тела, чтобы потребитель мог различить, пришел ли 404 из контейнера илиapplication: 

{
   "error": "No job found for id ..."
}

Тем не менее, это решение не кажется мне чистым или действительно "переоцененным".

1 Ответ

0 голосов
/ 13 октября 2018

Лучше всего сохранить ваш статус 200 во всех случаях (в вашем заявлении).Здесь 200 означает, что ваше приложение может быть достигнуто.

Для всех других ошибок вы можете вернуть все остальные статусы (включая 200).

Например - 200: 

{
     "response" : "Ok",
     "responseCode" : 200
     "data" : {
               "jobId" : 1
      }
}

Например - 404: 

{
     "response" : "Not Found",
     "responseCode" : 404
     "data" : null
}

Ваш потребитель услуг может прослушивать ответ (тело), ​​который генерируется вашим приложением, а затем может различать любые ошибки, которые генерируютсяконтейнер и ваше приложение.

Это относится ко всем ответным сообщениям, которые вы хотите отправить в свое приложение.

Надеюсь, это было полезно для вас.

...