My software has many sub-projects which are built into dll's, and many methods are exported as they will be used by other dependent project. We now need to expose some of the functionality in multiple dll's as API to a different project these API's are very small subset compared to all the currently exported methods on the dll's. What is the best way to provide a minimal set of API's to the outside world?
I thought, if we provide separate set of .h files with only few minimal exported public methods, then that minimal set would only be usable by outside world, correct? Is this a standard practice? Any better alternatives?
The source code is in C++, VS2010, windows platform.
In addition to what @RemyLebeau said, only create a separate API if you intend to keep both up to date and are willing to put the extra work in to keep both synchronised.
In terms of security, it has already been mentioned that if the DLL exports the symbols then they can readily be called by other programs, so in that sense providing a subset offers no increase in security.
That means that the choice of creating a public API comes down to user convenience and need, and not technical concerns. Exposing a subset gives a strong hint to the users about which methods are meant to be used. These concerns are weighed against the cost of having to maintain an extra API.