Обработка ошибок Rest WebService

Question

Я использую RestWebservice для нескольких основных операций, таких как создание / поиск. Запрос xml выглядит примерно так

<customer> 
    <name/>
  .....
 </customer>

Для успешной операции я возвращаю тот же пользовательский XML с дополнительными полями, заполненными в нем (например, systemId и т. Д., Которые мы оставляем пустыми в запросе). с Response.Status = 2000

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

<errors>
<error> An exception occurred while creating the customer</error>
<error> blah argument is not valid.</error>
</errors>

Теперь я не уверен, является ли это правильным способом отправки ошибок клиенту. Возможно, он должен присутствовать в заголовке ответа.

Я буду очень признателен за любую помощь. Спасибо!

Answer 1

Правильный подход REST для ошибок - использовать коды состояния HTTP (как это звучит, как вы делаете). Существует множество их изумительных (, как вы можете видеть здесь ), и вы можете быть удивлены, увидев, сколько из них может соответствовать большинству обычных ситуаций.

Что касается дружественных сообщений об ошибках, у вас есть 2 варианта. Во-первых, вы можете предоставить текстовое описание кода состояния после кода состояния в ответе HTTP ( см. Статью Wikipedia по HTTP для получения дополнительной информации ). Этот текст определяется сервером, а не спецификацией HTTP, и дает вам некоторую гибкость в конкретном отправляемом сообщении; большинство серверных платформ дают вам возможность задавать этот текст программно. Тем не мение! Рекомендуется не злоупотреблять описанием кода состояния, поскольку нельзя гарантировать, что веб-клиент пользователя будет его читать или нет (в пользу чтения только кода состояния и использования стандартных описаний HTTP). Я бы рекомендовал использовать этот подход только в том случае, если описание вашего статуса простое и вы управляете сервером и клиентом (чтобы вы знали, что получаете). По моему опыту, этот подход работает довольно хорошо для диапазона кодов 5xx, но я бы не стал его использовать для других целей.

Ваш второй вариант - это то, что вы уже делаете: вернуть код состояния ошибки и описание ошибки в качестве тела сообщения. Это лучшая практика; если это работает для вас, нет необходимости менять. Вероятно, полезно рассматривать это как «дополнительную информацию об ошибках», а не само сообщение об ошибке (которое будет текстом после кода состояния в ответе HTTP).

Answer 2

Я бы обернул XML в оболочку «Запрос» или «Ответ».

например.,

<customerrequest>
  <customer>
    ..
  </customer>
</customerrequest>

и, что более важно:

<customerresponse>
  <status>success | failure</status>
  <customer> <!-- If success -->
     ...
  </customer>
  <errors> <!-- If failure -->
     <!-- never underestimate the value of having a machine-friendly error code 
          for each possible error, or critical/non-critical errors -->
     <error code="0001">An error occurred</error>
  </errors>
</customerresponse>

Это также означает, что по мере развития вашей службы вы можете добавлять дополнительные поля, не относящиеся к данным, в соответствии с требованиями тегов запроса / ответа. Или ссылочный номер. Или детали аутентификации.

Если бы вы использовали SOAP, вы могли бы использовать существующую обработку ошибок, встроенную в SOAP, хотя я лично нашел ее довольно ограниченной (не то, чтобы я исследовал ее слишком глубоко).