servicio Web: Cuerda de parámetros o escribe el Complejo Parámetros

Question

¿Es más o menos aceptable (es decir, estándar) para crear un servicio público expuesta en la web con estas firmas de método:

ThisMethodDoesSomething(ComplexType param) 

ThisMethodDoesSomethingElse(AnotherComplexType param) 

O esto:

ThisMethodDoesSomethingAndSomethingElse(string xml) 

¿Dónde se realiza la operación depende de la cadena XML pasada a un único método de hacerlo todo? Siempre he ido con lo primero, pero un compañero de trabajo prefiere lo último y estoy tratando de sopesar los pros y los contras de ambas estrategias antes de comenzar un nuevo proyecto. ¿Cuál es más aceptado y más fácil para que el público trabaje y por qué?

Answer 1

Prefiero (y esa es la palabra operativa, prefiero, porque no hay un estándar para esto) una cadena XML compleja que explica la acción. Puede ver esto desde my open-source project.

Algunas de las razones que lo prefiero ...

1. Sus acciones son un lenguaje interpretado que puede flexionar.
2. Las acciones se pueden combinar en un solo viaje de red.
3. XML permite la expansión del conjunto de características sin alterar las características anteriores.
4. La jerarquía XML permite que las acciones actúen sobre las acciones del servidor.

Answer 2

Anteriormente hubiera preferido este último, porque no estaba seguro, si en la situación de plataforma cruzada, cada cliente SOAP sería capaz de consumir los tipos complejos correctamente. Así que pensé en una llamada SOAP, que solo toma y devuelve (XML-) Las cadenas no me darán dolor de cabeza. Mientras tanto, experimenté que, en general, no hay problema con el primer enfoque, al menos para que .Net interactúe con JAVA/AXIS y viceversa. Todavía estoy viendo para hacer que el tipo complejo no sea demasiado complejo.

Supongo que ThisMethodDoesSomething() y ThisMethodDoesSomethingElse() son operaciones atómicas? Si esto no es el caso (ThisMethodDoesSomethingElse() requiere una llamada al ThisMethodDoesSomething() para ejecutar), el primer enfoque es un no ir.

Answer 3

Su pregunta me parece una cuestión de interfaces de grano grueso frente a grano fino a primera vista. Por otro lado, siento que el segundo enfoque está llevando el grano grueso al extremo, si sabes a qué me refiero. Pierdes toda verificación de tipo. Hace que la implementación sea muy difícil: necesitaría una gran cantidad de casos dentro del código de respaldo para averiguar realmente de qué se trata la solicitud. ¿Qué devolverá el método? Supongo que si solo está obteniendo una cadena como parámetro, devolverá otra cadena. Como es una Cadena, y supongo que es una representación de cadena de un documento XML, tendrá que hacer que el análisis sea parte de su código de respaldo. A medida que la interfaz se hace más grande, supongo que estos se convertirán en métodos divinos. La lista continúa :)

Como nota al margen, no creo que estoy abogando por interfaces muy finas. Debe haber un equilibrio entre los dos. Una regla empírica para mí sería pasar siempre un elemento.

Answer 4

Normalmente, creo un esquema xml para describir los mensajes que formarán mi interfaz. Luego, usando un xsd para el generador de clases como Castor o Microsoft xsd.exe, creo mis clases de implementación.

Answer 5

Nunca enviaría una cadena XML. En primer lugar, "XML" no es lo mismo que "cadena". No siguen las mismas reglas.

Cualquier cliente razonable puede aceptar un tipo complejo que consta de tipos primitivos y listas o matrices de tipos primitivos, de forma recursiva (sintaxis de 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;} 
} 

Francamente, cualquier cliente que no puede hacer frente a algo así como el arriba merece ser retirado.