I can think of defining different interfaces and the class implementing those interfaces. A ‘user’ would see just those APIs which are defined in the interface, the one he is using to access the class.
This is one way to make API’s simple and easy to use. But this is definitely not ‘Progressive’ disclosure.

For that, we can design a class with very basic methods plus a method like ‘GetAdvanceControl()’ which would return an object with advance stuff.

Oh, I didn’t use the term ‘conventional wisdom’ in any bad sense. I was trying to point out that most advice from experts points that path to follow. That is the ‘right’ answer. Hardly anyone explains the true thought behind it. (Much like the real reasons for using Hungarian Notations).

I normally hate to just follow rules unless I understand the value they bring. And although I dislike the very widespread practice of people coding too many things inside a function (mostly stuff which is not reflected by the name of the function); I am also uncomfortable designing APIs which are loaded with various method calls.

Yes! Progressive Disclosure sounds interesting, although the right pattern for implementing such a system still probably needs to be discovered.

Still, you could make a case that it complicates an API to have so many different methods. You could even view it as a tradeoff of API usability versus code readability. I just think combining methods just masks the complexity without really eliminating it.

If you end up with a lot of methods, think about progressive disclosure. Is there a way to surface the most commonly used methods and classes while making the less common methods accessible, but less apparent? I haven’t had a chance to put that idea into practice but I’m keeping an eye out.

In terms of an API, the most common question that I face is whether there should be fewer API methods which do a lot of things depending on the control information provided in the parameters? Or there should be many methods, with each one doing exactly one thing.

Conventional wisdom suggests the latter, however, I somehow have had trouble digesting that. I keep thinking there needs to be a middle path somehow, but where to strike that balance is something that eludes me.

Any help?

Just FYI, since we worked together I’ve become a convert to the importance of usability. Everything we do as engineers is to enhance human experience – our own or that of others. (Even if you are designing a bridge – you don’t want your users to get wet, right?!) It takes a lot of introspection and self-criticism to make human factors truly influence your design, but the results can be delightful.