What I may not have stressed hard enough while discussing URI-based load-balancing was that while the approach is completely opaque to end-users, it does require a load-balancer that is capable of examining the URI and making decisions based on it...usually this is done via regular expression pattern matching and it is an advanced load-balancing technique. As I say, the big win is that end-users do not know it is happening and do nothing special at all.

A poor-man's approach is IP-based load-balancing, essentially where servers (or server farms) are dedicated to a specific task and called directly ... say http://lapi.example.com versus http://www.example.com. The advantage of this approach is the ease with which it can be deployed, it doesn't take any particular special knowledge or infrastructure to deploy or use. The disadvantage of this approach is that end-users and even some applications may not understand that lapi.example.com and www.example.com are two distinct interfaces into the same data and thus confusion can rule.

Such confusion is something that a small or medium-sized company can deal with effectively with training and osmosis between users but large organizations will usually find it more efficient to use the URI approach as training costs will be very large and swamp the deployment costs.

There is, of course, no reason that both approaches can't be taken -- using IP-based load-balancing to direct applications to particular server farms and then further refining the server choice using URI-based load-balancing. In very large, complex environments where there are many separate and distinct applications each jockeying for their own resources, it might make sense to do this (but I'm not sure any such site actually exists today).