One of the goals may be to abstract the way the network data is accessed.
Such abstraction can be very abstract:
public loadProducts(currentCategory) returns list of Product {
var productsFactory = dataAccess.factory.createProductsFactory();
var productsOfCategory = productsFactory.loadProducts(currentCategory);
return productsOfCategory;
}
Here, the caller don't know if products are loaded from a database, an XML file, a REST request or something completely different. It makes it very easy to replace one data source by another, for example migrate all data from a REST service to a database.
Or the abstraction may be more transparent:
public doPostRequest(parameters) returns Stream {
... // Use library A to do the request. if you need to switch to library B later, this
// is not an issue.
}
Here, the caller knows that the library is using a network resource. While being transparent, such library can still be useful when migrating from one way to do HTTP requests to another.
In .NET Framework, for example, there are at least three ways to do HTTP requests, not counting all the third party libraries one can use. Picking one way and sticking with it is a solution, but later, migrating to another implementation would be painful. Another solution is to create your own layer, abstracting the actual implementation: if a new version of .NET Framework will be released and you want to use a new way of doing HTTP requests, you change the code in one place.
