Web Service interface - Complex Type as parameter?

Question

Hello

Just looking for some feedback on best-practices regarding Web Service interface design.

I have two options:

Option 1

public string GetSomeData(SomeCriteriaClass criteria);

where SomeCriteriaClass is defined as:

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

Option 2

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

Which is the preferred option? It seems like a conflict of design patterns - 1 is to wrap up parameters in a class, but the other is keeping the web service interface flexible and open.

The second question is - if we choose Option1 - how do you call this via a URL?

Thanks

Answer 1

You can go the hard way and implement option #1, using SOAP. With SOAP you can define complex data types. On the other hand, you can do it the "hack" way as in option #2, using REST and just encode the parameters in either the URL or the HTTP POST message.

Answer 2

The term "web service" is often used for two different things.

• A technology: using HTTP(S) as a protocol for interprocess communication.

• An architectural approach: Service Oriented Architecture.

If we're talking about web service as just a technology then you have a lot of options: you can use HTTP GET (this is the one using URL params) or HTTP POST (the data is in the body of the HTTP message). For HTTP POST the payload can be SOAP or just any propriatery stuff.

If we're talking about service oriented approach and web services as a tool then HTTP+SOAP is the most standard way to go.

If we consider a web service method just an implementation of a service operation then use the signature below which emphasizes this approach:

public FooResponse FooOperation(FooRequest request);

It means that an operation has a request and a response document (even if any of these are empty) and you can separate the service contract (what operations do you expose) and the data contract (how do you compose the request and response messages). See this article for more details about it: Principles of Service Design Service Patterns and Anti-Patterns

Conclusion:

• If you don't care about SOA just want to invoke a method via HTTP then Option 2 is clear and simple.
• But if you're building SOA services then use the "document-centric" signature. Option 1 is a mixture of both and is not recommended.

Answer 3

Option 1 public string GetSomeData(SomeCriteriaClass criteria); is nice way to implement webservice cause here u are using SOAP and document-oriented term. And option2 is for basic java developer those don't too much concentrate on design pattern.

Let's take scenario - After using option 2, suppose you wan to add 3 more varibale in SomeCriteriaClass.java then , what way you will choose.. add 3 more parameter to GetSomeData() method or declare in SomeCriteriaClass.java.

A good design-pattern follower, choose to declare in SomeCriteriaClass.java not to add in GetSomeData().