With the advent and adoption of REST as the pseudo standard (there is no W3C standard for it, the canon of REST is a dissertation you can find online) for public APIs, a new way of doing load balancing is possible. You can combine layer 7 load balancing with REST to have some interesting architectures. A load balancer doing layer 7 load balancing actually inspects the HTTP header, plus the URL and even the file type to figure to which server, or group of servers, to forward the request. The Big IP F5 load balancers have a way of entering complex rules to determine the load balancing algorithm according to layer 7 data.
So, suppose you are developing a web biography management application. You create a REST API that your RIA client can access to get biography data (let's pretend wikipedia does not exists). Since you followed the REST pseudo standard to the letter, when the application hits www.yourfooapplication.com/person/TuringAlan the servers return the biography of Alan Turing. Then if your application hits www.yourfooapplication.com/person/DijsktraEdsger the servers return the biography Edsger Dijsktra. The application becomes a huge hit and you need to add more servers besides the one application server and the one database server you have. You will also need to load balance across servers. What are your options?
The traditional option is to use sharding. If you have two application servers and and two database servers, then load balance against the application servers and put the two database servers in a cluster. The problem is that managing a database cluster is usually difficult, particularly without excellent storage. Now, you could divide the data between the two database servers. The biographies from A to M will go one database server, the biographies from N to Z will to another. By going to another I mean, that one database server will only have the data from A to M and the other will only have the data from N to Z. This seems like a great idea. The size of the individual databases is reduced and there is no need to cluster the databases. Performance will most definitively improve. Of course, now every single server is a single point of failure and the application has no high availability. This could be solved with HA pods using the same principle. Then it is just a matter of configuring the load balancer to forward request matching www.yourfooapplication.com/person/A* to M* to one server and www.yourfooapplication.com/person/N* to Z* to another.
This architecture does not work. What if later down the road you need to implement a search feature? How will you organize searches across two databases? With slow across DBs join statements? This example is obvious, but the problem could be more subtle. For example, a job posting site that decides to use this strategy to load balance for jobs in certain regions. This application could be logically partitioned into states. The each state is managed by a different set of servers. So, jobs in California will be managed by one set of servers, while jobs in Oregon will be managed by another. This architecture also breaks down if a user needs to look for jobs in two states at the same time.
Layer 7 load balancing is a powerful tool. And there is room for it to be used in combination with REST APIs. Just keep in mind, that the Database Layer can not be logically divided for one application.