Каков хороший шаблон дизайна для возвращаемых значений веб-метода?

Question

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

Answer 1

Мне нравится шаблон объекта Request / Response, в котором вы инкапсулируете свои аргументы в один класс запроса [Operation], который имеет простые общедоступные свойства.

Что-то вроде AddCustomerRequest, которое будет возвращать AddCustomerResponse.

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

Еще один хороший пример - сделать все это производным от простого интерфейса IMessage, где вашей общей конечной точкой является что-то вроде Process (params IMessage [] messages) ... таким образом, вы можете передавать несколько операций в одной сети запрос.

Answer 2

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

Answer 3

+ 1 для ответа Бена.

Кроме того, я предлагаю учесть, что общий ответ позволяет использовать несколько элементов ошибок / предупреждений, чтобы сделать ответ максимально полным и действенным. (Вы хотите использовать компилятор, который остановился после первого сообщения об ошибке, или компилятор, который сказал вам как можно больше?)

Answer 4

Неисправности мыла являются стандартной практикой, когда вызывающее приложение является клиентом Soap. В таких случаях, как COM-клиент, использующий XMLHTTP, Soap анализируется как XML, а ошибки Soap не могут быть легко обработаны. Голосовать за @Ben Scheirman еще нельзя, но еще +1.