Веб-служба: параметр с одной строкой или параметры сложного типа - PullRequest
Новая
       12

Веб-служба: параметр с одной строкой или параметры сложного типа

6 голосов
/ 16 августа 2010

Является ли более или менее приемлемым (т. Е. Стандартным) создание публичного веб-сервиса с сигнатурами следующих методов: 

ThisMethodDoesSomething(ComplexType param)

ThisMethodDoesSomethingElse(AnotherComplexType param)

Или это: 

ThisMethodDoesSomethingAndSomethingElse(string xml)

Где выполняемая операция зависит от XML-строки, передаваемой одному методу "сделай сам"? Я всегда выбирал первое, но мой коллега предпочитает второе, и я пытаюсь взвесить все за и против обеих стратегий, прежде чем мы начнем новый проект. С чем общепризнанно и с кем легче работать и почему?

Ответы [ 5 ]

2 голосов
/ 22 сентября 2010

Я бы никогда не отправил строку XML.Прежде всего, «XML» - это не то же самое, что «строка».Они не следуют одним и тем же правилам.

Любой разумный клиент может принять сложный тип, состоящий из примитивных типов и списков или массивов примитивных типов, рекурсивно (синтаксис C #): 

public class ComplexType1
{
    public int IntegerProperty {get;set;}
    public int[] ArrayOfIntegers {get;set;}
    public List<int> ListOfIntegers {get;set;} // Same as ArrayOfIntegers
}

public class ComplexType2
{
    public ComplexType1 CT1 {get;set;}
    public List<ComplexType1> LCT1 {get;set;}
}

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

1 голос
/ 14 сентября 2010

Раньше я бы предпочел последнее, потому что я не был уверен, что в кроссплатформенной ситуации каждый клиент SOAP сможет правильно использовать сложные типы. Поэтому я подумал, что вызов SOAP, который просто принимает и возвращает (XML-) строки, не доставит мне головной боли. Между тем, как я понял, обычно нет проблем с первым подходом, по крайней мере, для .Net, взаимодействующего с JAVA / AXIS и наоборот. Я все еще смотрю, чтобы сделать сложный тип не слишком сложным.

Я предполагаю, что ThisMethodDoesSomething() и ThisMethodDoesSomethingElse() являются атомарными операциями? Если это не так (ThisMethodDoesSomethingElse() требует вызова ThisMethodDoesSomething() для выполнения), первый подход - это не ход.

0 голосов
/ 22 сентября 2010

Я обычно создаю XML-схему для описания сообщений, которые будут формировать мой интерфейс.Затем, используя генератор классов xsd, такой как Castor или Microsoft xsd.exe, я создаю свои классы реализации.

0 голосов
/ 16 сентября 2010

Ваш вопрос звучит для меня как вопрос о крупнозернистых и мелкозернистых интерфейсах на первый взгляд.С другой стороны, я чувствую, что второй подход - это грубая грануляция до крайности, если вы понимаете, о чем я.Вы теряете все проверки типов.Вы делаете реализацию очень сложной - вам понадобится много случаев, если внутри кода поддержки действительно выясняется, о чем идет речь.Что вернет метод?Я предполагаю, что если вы просто получаете строку в качестве параметра, вы вернете другую строку.Поскольку это String, и я предполагаю, что это строковое представление документа XML, вам придется сделать синтаксический анализ частью вашего кода поддержки.Поскольку интерфейс становится больше, я предполагаю, что они превратятся в божественные методы.Список можно продолжить:)

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

0 голосов
/ 16 августа 2010

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

Некоторые причины, по которым я предпочитаю это ...

  1. Ваши действия - это интерпретируемый язык, который может сгибаться.
  2. Действия могут быть объединены в одну сетевую поездку.
  3. XML позволяет расширять набор функций, не нарушая прошлых возможностей.
  4. Иерархия XML позволяет действиям воздействовать на действия на стороне сервера.
...