I suppose it depends. "Thoroughly" and "Ever" are pretty strong words. After all, you can spend so much time designing and planning that your project sponsors get tired of seeing no progress. (I know this from experience.) Similarly, if you're not willing to change your API, then you prevent it from evolving and improving.

Instead, I think it's wiser to pick the most common operations, design them orthogonally, and then let the API grow organically as needed. If you start with 20% that you'll need 80% of the time, you've got something you can base continued progess on.

It's hard to be more specific without details, but let's assume you're building a custom API for handling a database, one that matches your local standards and idioms. Given that, you then know the basic operations: create, alter, insert, delete, select, update, and so on. Implement those quickly and then produce a simple front-end for testing and evaluation. Let people see that and start providing input. You'll start getting immediate feedback and they'll see appreciable progress.

You have to use care and common sense, of course. After all, you don't want to reinvent the wheel (as in there are a lot of existing database API's available that already handle those atomic operations) nor do you want to short-sheet those using your API.

Inflexibility leads to brittleness and breakage (as it does in real life). If you do not allow yourself to back-track, re-design, improve, update, maintain, and so on, then how will you ever improve quality, performance, and flexibility?

--f