Interface de service Web - Type complexe en tant que paramètre?

Question

Je suis à la recherche de commentaires sur les meilleures pratiques en matière de conception d'interface de service Web.

J'ai deux options:

Option 1

public string GetSomeData(SomeCriteriaClass criteria); 

où SomeCriteriaClass est défini comme:

public int ID; 
public string Name; 
public string Property2; etc. 

Option 2

public string GetSomeData(int id, string name, string property2) 

Quelle est l'option préférée? Cela ressemble à un conflit de modèles de conception - 1 consiste à conclure des paramètres dans une classe, mais l'autre maintient l'interface de service Web flexible et ouverte.

La deuxième question est - si nous choisissons Option1 - comment appelez-vous cela via une URL?

Merci

Answer 1

Vous pouvez aller à la dure et mettre en œuvre l'option 1, en utilisant SOAP. Avec SOAP, vous pouvez définir des types de données complexes. D'autre part, vous pouvez le faire par "hack" comme dans l'option # 2, en utilisant REST et simplement encoder les paramètres dans l'URL ou le message HTTP POST.

Answer 2

Le terme «service Web» est souvent utilisé pour deux choses différentes.

• Une technologie: utilisant HTTP (S) comme protocole pour la communication interprocessus.

• Une approche architecturale: Architecture orientée services.

Si nous parlons de service Web comme une simple technologie alors vous avez beaucoup d'options: vous pouvez utiliser HTTP GET (c'est celle qui utilise l'URL params) ou HTTP POST (les données sont dans la corps du message HTTP). Pour HTTP POST, la charge utile peut être SOAP ou n'importe quel contenu propriétaire.

Si nous parlons d'approche orientée services et de services Web comme outil, alors HTTP + SOAP est la solution la plus courante.

Si l'on considère une méthode de service Web juste une mise en œuvre d'une opération de service puis utilisez la signature ci-dessous qui met l'accent sur cette approche:

public FooResponse FooOperation(FooRequest request); 

Cela signifie qu'une opération a une demande et un document de réponse (même si l'un d'entre eux est vide) et vous pouvez séparer le contrat de service (quelles opérations exposez-vous) et le contrat de données (comment composez-vous les messages de demande et de réponse). Voir cet article pour plus de détails à ce sujet: Principles of Service Design Service Patterns and Anti-Patterns

Conclusion:

• Si vous ne se soucient pas de SOA veux juste appeler une méthode via HTTP, l'option 2 est claire et simple.
• Mais si vous construisez des services SOA puis utilisez la signature « centrée sur les documents ». L'option 1 est un mélange des deux et n'est pas recommandée.

Answer 3

Option 1 chaîne publique GetSomeData (critères SomeCriteriaClass); est une bonne façon d'implémenter webservice parce que vous utilisez SOAP et terme orienté document. Et option2 est pour le développeur java de base ceux qui ne se concentrent pas trop sur le motif de conception. Prenons un scénario - Après avoir utilisé l'option 2, supposons que vous vouliez ajouter 3 variables de plus dans SomeCriteriaClass.java, alors de quelle manière vous choisirez .. ajoutez 3 paramètres supplémentaires à la méthode GetSomeData() ou déclarez dans SomeCriteriaClass.java.

Un bon suiveur modèle de conception, choisissez de déclarer dans SomeCriteriaClass.java de ne pas ajouter à GetSomeData().