You're actually probably better off sending them all at once.
Why are they expensive? And why does that matter even on a mobile application (even if, for the sake of argument, you're doing it natively)? Because it's the act of making the connection itself that makes it expensive. To open an HTTP connection, the client and the server go through a number of steps:
- DNS lookup. Is the server actually there? Can the client connect to it?
- SYN It is? Great! Start the handshake transaction (this is known as a "SYN" packet).
- SYN-ACK The server responds with the next step of the handshake transaction, known as a "SYN-ACK" packet.
- ACK The client responds again, with the third, and final step of the handshake. If all three steps are successful, then the connection is established. Now, we can actually get to our request.
- Send the request. This is where your data is actually getting sent.
- Wait for response. The server has to do something with request, which takes time, especially if a database or heavy calculations are involved.
- Receive Response The server sends back the response. This takes time based on the response size and connection integrity, just like the send request step.
- Load The client now has to do something with the information it got back from the server. Usually, it's rendering it to an output device, or triggering another event.
- FIN The client sends a "FIN" packet that closes the HTTP connection
(Check out this breakdown on the anatomy of an HTTP connection for more information.)
HTTP Requests Have Many Network-Based Failure Points Take a look again at the above list of steps that a transaction goes through. Six of the 9 steps will cause the connection to fail and your data to be lost if the network connection is dropped. That's a lot of failure points. You repeat those failure points every time you make an HTTP request. So, the more times you make the request, the more chances you have of a request failing due to network issues.
JSON Objects Aren't That Big JSON objects, being only text, are quite tiny when done properly. They can get pretty large, but you'd have to be sending a ton of data (most likely more data than you actually need and can probably filter down, such as search results with too vague a search term) to do so. Compared to the cost of making the HTTP connection, you have to get pretty large to offset it with too much JSON data.
HTTP Requests Have Nothing to do with SQL Server You should have an application layer, which exposes an API to your client, between your client and SQL Server. As such, you can format the database requests in a way that makes sense for it, regardless of what you do on the client side.