I've blogged before about building mini-APIs into Rails. I'm not the only one -- Jamis Buck wrote a post praising Marcel Molina, Jr. for his talent at doing the exact same thing. I think this is a useful technique which Ruby programmers need to use more often.
I think the reason you don't see people using mini-APIs as often as they should is because people don't really understand why it's a good idea, and where you should use it.
Mini-APIs come midway between DSLs and refactoring. Refactoring is often used as a synonym for debugging, but refactoring is actually the opposite of debugging. Instead of changing the code to get it to work properly, you're changing the code without changing the functionality at all. Any time you find something repetitive or inelegant, you tidy it up a bit. Just a tiny, tiny bit.
The end result is a cleaner design, but refactoring isn't about redesign. It's about tidying up the code and getting a cleaner design as a side effect. It's actually TDD in reverse. With both refactoring and TDD, your goal is to produce a clean design, but the way you get there is not by designing anything, but rather doing lots of small things which, in the long run, if done consistently, will result in a good design without any explicit designing ever actually taking place. It's a very Zen idea.
DSLs, of course, are all about creating new mini-languages which you or your client programmers can use to write code not in Ruby or in Rails but in the mini-language. Your goal is to represent the problem space so succinctly that a business user can code in terms of business rules without ever needing to learn a fully-fledged language. Rails is a great example of this, and yet all the DSL features of Rails emerged organically from DHH's desire to eliminate repetition -- which is to say, the DSL aspect of Rails is a result not of deliberate design but of consistent and diligent refactoring.
(By the way, I'm sorry I don't have a link to back this up, but I'm absolutely certain of it. I've read a gazillion blogs and listened to every podcast DHH was ever on, and the proof of this statement is definitely out there somewhere. I just don't have the time to track it down at the moment.)
Anyway, if DSLs are really just the product of very extensive refactoring, and mini-APIs sit midway between refactoring and DSLs, what I'm saying is that mini-APIs emerge from streamlining repetitive code. And that's it. That's exactly what happens. If you want to get to a DSL, the way to do it is not to cook up a DSL right away. You start with messy code and you chip away at it until it takes the shape of a DSL -- like a sculptor shaping marble. You'll know you're halfway there when you've got a mini-API.
I think this is why you don't see people using mini-APIs enough. You often see programmers who want to write a big fancy DSL, because that's the hip new thing, and you often see programmers who'll write the same code twice because they're in a hurry. What's rare is the programmer who'll go back and rewrite repetitive code to make it slim and elegant, and what's very, very rare is the programmer who's going to rewrite the same piece of code until it's as elegant as it can possibly be.
Unfortunately this is exactly the type of programming which results in powerful frameworks like Rails! It is very literally exactly the programming method which gave the world Rails in the first place.
DHH has tons of fans. If you're a DHH fan, think about what I'm about to say, and act on it. Nearly every one of DHH's fans is writing code like the code DHH wrote. Very, very few of DHH's fans are writing code the way DHH writes it. But the difference between doing something just like something somebody else did and doing something the way somebody else did it is the difference between being an imitator and being a student.
Don't imitate. Study.