Можно ли вернуть объекты из WebService?

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

Ответов (11)

Решение

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

Однако, если у вас есть сложные типы, вам нужно пометить объект атрибутом [Serializable]. То же самое и со сложными типами как со свойствами.

Так, например, вам необходимо иметь:

[Serializable]
public class MyClass
{
    public string MyString {get; set;}

    [Serializable]
    public MyOtherClass MyOtherClassProperty {get; set;}
}

Да: в .NET это называется сериализацией, когда объекты сериализуются в XML, а затем восстанавливаются службой-потребителем обратно в исходный тип объекта или суррогат с той же структурой данных.

Если объект можно сериализовать в XML и описать в WSDL, тогда да, можно возвращать объекты из веб-службы.

.NET автоматически делает это с сериализуемыми объектами. Я почти уверен, что Java работает точно так же.

Вот статья, в которой рассказывается о сериализации объектов в .NET: http://www.codeguru.com/Csharp/Csharp/cs_syntax/serialization/article.php/c7201

Там, где это возможно, я транспонирую объекты в XML - это означает, что веб-служба более переносима - я могу получить доступ к службе на любом языке, мне просто нужно создать парсер / транспозитор объектов на этом языке.

Поскольку у нас есть файлы WSDL с описанием службы, в некоторых системах это почти автоматизировано.

(Например, у нас есть сервер, написанный на чистом питоне, который заменяет сервер, написанный на C, клиент, написанный на C++ / gSOAP, и клиент, написанный на Cocoa / Objective-C. Мы используем soapUI в качестве среды тестирования, который является написано на Java).

@Brian: Я не знаю, как все работает в Java, но в .net объекты сериализуются в XML, а не в строки base64. Веб-сервис публикует файл wsdl, содержащий определения методов и объектов, необходимые для вашего веб-сервиса.

Я надеюсь, что никто не создаст веб-сервисы, которые просто создают строку base64

Можно возвращать объекты из веб-службы с помощью XML. Но предполагается, что веб-службы не зависят от платформы и операционной системы. Сериализация объекта просто позволяет вам сохранять и извлекать объект из байтового потока, такого как файл. Например, вы можете сериализовать объект Java, преобразовать этот двоичный поток (возможно, с помощью кодировки Base 64 в поле CDATA) и передать его клиенту службы.

Но клиент мог бы восстановить этот объект, только если бы он был основан на Java. Более того, для сериализации объекта и его точного восстановления требуется глубокая копия. Глубокие копии могут быть дорогими.

Лучше всего создать схему XML, представляющую документ, и создать экземпляр этой схемы со спецификой объекта.

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

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

Я не могу согласиться с этим, поскольку это несколько узкий комментарий. Использование веб-службы, которая может сериализовать объекты домена в XML, означает, что это упрощает работу клиентов с одними и теми же объектами домена, но это также означает, что эти клиенты ограничены использованием той конкретной веб-службы, которую вы предоставили, и она также работает в наоборот, позволяя другим клиентам ничего не знать об объектах вашего домена, но при этом взаимодействовать с вашим сервисом через XML.

Даниэль Аугер:
Как уже говорили другие, это возможно. Однако, если и служба, и клиент используют объект, который имеет одно и то же поведение домена с обеих сторон, вам, вероятно, вообще не нужна служба.

lomax: Я не согласен с этим, поскольку это несколько узкий комментарий. Использование веб-службы, которая может сериализовать объекты домена в XML, означает, что это упрощает работу клиентов с одними и теми же объектами домена, но это также означает, что эти клиенты ограничены использованием той конкретной веб-службы, которую вы предоставили, и она также работает в наоборот, позволяя другим клиентам ничего не знать об объектах вашего домена, но при этом взаимодействовать с вашим сервисом через XML.

@ Lomax: Вы описали два сценария. Сценарий 1. Клиент повторно переводит XML-сообщение в тот же объект домена. Я считаю это «возвращением объекта». По моему опыту, это плохой выбор, и я объясню это ниже. Сценарий 2: Клиент регидратирует XML-сообщение во что-то иное, чем тот же объект домена: я на 100% поддерживаю это, однако я не считаю, что это возвращает объект домена. Это действительно отправка сообщения или DTO.

Теперь позвольте мне объяснить, почему истинная / чистая / не сериализация объекта DTO в веб-сервисе обычно является плохой идеей. Утверждение: для того, чтобы сделать это в первую очередь, вы должны либо быть владельцем как клиента, так и службы, либо предоставить клиенту библиотеку для использования, чтобы они могли повторно преобразовать объект в его истинный тип. Проблема: этот объект домена как тип теперь существует и принадлежит двум полусвязанным доменам. Со временем может потребоваться добавить поведение в одну область, которое не имеет смысла в другой области, и это приведет к загрязнению и потенциально болезненным проблемам.

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

Прошу прощения за краткость своего первоначального ответа. Я надеюсь, что это до некоторой степени проясняет мое мнение. Lomax, вроде бы наполовину согласны;).

JSON - довольно стандартный способ передачи объектов по сети (как подмножество javascript). Во многих языках есть библиотека, которая преобразует код JSON в собственный объект - см., Например, simplejson в Python.

Дополнительные библиотеки для использования JSON см. На веб-странице JSON.