There are two questions to answer early on when configuring Solr and thinking about who the consumers of the search services are—"Are you providing generic search services that may be consumed by a variety of end user clients?" or "Are you providing search to a specific application?"

If you are providing generic search functionality to an unknown set of clients, then you might just have a single request handler handling search requests at /solr/select, which provides full access to the index. However, it is likely that Solr is powering interfaces for one or more applications that you know are going to make certain specific kinds of searches.

For example, say you have an e-commerce site that supports searching for products. In that case, you may want to only display products that are available for purchase. A specifically named request handler that always returns the stock products (using appends, as fq can be specified multiple times) and limits the rows to 50 (using invariants) would be appropriate:

<requestHandler name="/products" class="solr.SearchHandler" >
  <lst name="invariants">
    <int name="rows">50</int>
  </lst>
  <lst name="appends">
    <str name="fq">inStock:true</str>
  </lst>
</requestHandler>

However, the administrators of the same site would want to be able to find all products, regardless of whether they are in stock or not. They would be using a different search interface and so you would provide a different request handler that returns all of the information available about your products:

<requestHandler name="/allproducts" class="solr.SearchHandler" />

Later on, if your site needs to change, or if the internal searching site changes, particularly with respect to tuning search relevancy, you can easily modify the appropriate request handler without impacting other applications interacting with Solr. In particular, if you have complex query parsing logic, you can hide much of that behind the request handler, so that your clients can work with a simpler query structure.