Which is better? High number of web service calls (SOAP messages) or high amount of data in single Soap Message?

Question

I am designing a mobile application which gets server data through SOAP messages.

I wanted to know what is the best practice:

• More number of web service calls fetching less data in each SOAP message call.
  OR
• I get all data in a single web service call but then the length of SOAP message would be large.
  
  Wouldn't the high amount of data in a single soap message create data connectivity issues for mobile subscriber.
  
  In my application for a particular year I have to get names of all car manufacturers and model names for all cars by each manufacturer. I have two plans:
• As the user selects a year I send a web service which will get all the data.
• As the user selects a year I get the names of manufacturers and then when user selects a manufacturer i get all the models for that manufacturer.
  please help by telling me which approach should I take.

* PS: *user can have many vehicles and if I use second approach then web services will be called for every vehicle.

Answer 1

Couple of points

1. As pointed out in the comment Use JSON instead of SOAP where ever possible, SOAP is very heavy weight and is not being recommended these days.( look at all the endpoints being exposed by Google and others - most of them use JSON )

2. If the xml size is becoming too large ( beyond few kilobytes) it is better to make multiple calls rather than loading a large object in memory.

Answer 2

What sort of size responses are we talking about - min / max / typical?

There's no simple answer to this question as it depends on what triggers the web-service request eg is it in response to a user action, timed etc.

Latency is one of the killers over mobile networks (more important than low bandwidth) so in theory you should aim for a minimum number of requests.

but...

There's no point in making large requests if you don't need the data.

My guess is you're going to have to test with different response sizes to find the sweet spot.

Also don't forget to allow gzip/deflate in the request and compress the response from the server.

If possible I'd also go for a RESTful approach and ensure the GET responses are cacheable

Answer 3

On a mobile connection, I'd opt for larger responses because of the network latency. It's better to fetch a bunch of things in one go than to fetch each item in a new roundtrip. This will keep your app fast.

Even larger responses can be efficiently handled without needing to store those in memory if you use a library that can "stream" the response.