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

Question

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

Answer 1

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

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

Так, например, вам нужно иметь:

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

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

Answer 2

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

Answer 3

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

Answer 4

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

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

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

Answer 5

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

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

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

Answer 6

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

Дополнительные библиотеки JSON можно найти на веб-странице JSON

Answer 7

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

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

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

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

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

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

Answer 8

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

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

Answer 9

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

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

Answer 10

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

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