Джерси (REST) выдает исключение и сопоставляет с ошибкой HTTP или возвращает пользовательский код ошибки?

#rest #exception-handling #jersey

#rest #обработка исключений #джерси

Вопрос:

По сути, я написал службу REST, и моя бизнес-логика требует от меня проверки входных данных. Например, убедитесь, что формат номера телефона (###)###-####. Если это не так, он должен вернуть неверный номер телефона. Кроме того, мне нужно записывать все действия службы. Поэтому, когда клиент запрашивает систему, он может узнать, какое действие было последним. Т.е.:

ДЕЙСТВИЕ: ДОБАВИТЬ — УСПЕШНОЕ ДЕЙСТВИЕ: ДОБАВИТЬ — НЕВЕРНЫЙ НОМЕР ТЕЛЕФОНА

Итак, теперь я думаю, нужно ли мне создавать свои собственные коды ошибок или просто использовать HTTP-коды по умолчанию, а также записывать их в «журнал»

Довольно новый для стиля REST, поэтому, если моя логика отключена, дайте мне знать…

Так что я должен..

 public void callPerson(String phone)
{
    try
      validate(phoneNumber)
      call person
    catch
        throw Invalid Phone Number
    finally
       record status to DB
}
 

или

 public myStatusCode callPerson(String phone)
{
    try
      validate(phoneNumber)
      call person
    catch
        return myStatusCode
    finally
       record status to DB

}
 

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

Также следует иметь в виду, что некоторые действия службы REST должны взаимодействовать со старой службой, ориентированной на «сообщение», где ответ и код ошибки содержатся в ответном сообщении XML…

Есть предложения? Спасибо

Ответ №1:

Я бы рекомендовал код состояния HTTP 412 (сбой предварительного условия) и строковое сообщение об ошибке.

Комментарии:

1. Круто! И я полагаю, что клиенты REST могут легко прочитать это? Я привык к более ориентированному на сообщения сервису pre SOAP, где и запрос, и ответ представляют собой XML. Таким образом, помимо того факта, что клиент получает HTTP 200 OK для ответа, ему также необходимо проанализировать XML-ответ и получить коды состояния системы. И дополнительная информация, которую они запросили.

2. Код состояния не будет в теле XML. Ресурсы REST создают 3 вещи: 1. представление (в кодировке XML или другое) 2. заголовки (кэш, безопасность …) 3. код состояния. Каждый клиент способен получить эти 3 информации. В Java Джерси предлагает response.getStatus() , response.getHeaders() amp; response.getEntity(Person.class) . Присмотревшись, вы заметите, что Джерси выполняет демаршализацию за вас; вам не нужно анализировать ответ .

3. Хорошо, что, если клиент является приложением и хочет сохранить 412 (сбой предварительного условия) «Недопустимый номер телефона» в базе данных для целей аудита. GetStatus() вернет 412 как я получу значение «недопустимый номер телефона». По сути, я хочу создать очень легкий веб-сервис XML без тяжести SOAP и т. Д… REST кажется правильным, но теперь я застрял, используя коды ошибок HTTP, которые я не могу сопоставить с моими собственными и т. Д…

4. Да, REST кажется подходящим для вашей цели. response.getEntity (String.class ) достаточно, чтобы получить сообщение 412. В некоторых случаях сообщения об ошибках встроены в объект, это зависит от вас.

5. Хорошо, разбираемся в этом, значит, вы говорите, что я могу либо вернуть HTTP 412 — номер телефона недействителен, либо вернуть HTTP 200 с телом сообщения, включающим пользовательский код? Или HTTP 412 с телом сообщения, содержащим пользовательский код?