#web-services #architecture #service #message #n-tier-architecture
#веб-службы #архитектура #Обслуживание #Сообщение #n-уровневая архитектура
Вопрос:
Мы работаем с набором веб-служб и ищем наилучший вариант возврата ошибок потребителю веб-службы. Это текущий ответ:
Ответ
- Некоторые данные о сервере
- Некоторые данные о пользователе
- Некоторые результирующие данные выполнения транзакции
Итак, нам также нужно возвращать ошибки. вот наши варианты:
Составное сообщение
мы вернем два вида ответов в зависимости от того, была ли транзакция одобрена или произошла ошибка:
Первый:
- идентификатор типа (это сообщение сериализуется. поэтому мне нужно знать, с каким сообщением я имею дело, чтобы десериализовать последнюю часть)
- Некоторые данные о сервере
- Некоторые данные о пользователе
- Некоторые результирующие данные выполнения транзакции
Второй:
- идентификатор типа (это сообщение сериализуется. поэтому мне нужно знать, с каким сообщением я имею дело, чтобы десериализовать последнюю часть)
- Некоторые данные о сервере
- Некоторые данные о пользователе
- Ошибки
Необязательные поля
поля данных транзакции и ошибок будут необязательными. если ошибок нет, я буду знать, что оно было одобрено.
- Некоторые данные о сервере
- Некоторые данные о пользователе
- Некоторые результирующие данные выполнения транзакции
- Ошибки
Какой вариант более подходит?
Ответ №1:
Это спорное и скорее личное мнение, чем рекомендация.
Мое личное предпочтение — использовать необязательные поля, потому что код ошибки является возможным результатом операции. Я бы ожидал, что клиент всегда будет сначала проверять (необязательные) свойства ошибки возвращаемого результата перед анализом результатов. Это позволяет также возвращать неустранимые ошибки и частичные результаты вместе. Это делает Exclusive … Эксклюзив. Необязательный является более гибким.
Комментарии:
1. спасибо, Кронвейк, пример частичных результатов — действительно хороший аргумент в пользу необязательных полей. Я этого не осознавал. 1