Todd - this is an increasingly important scenario: mobile apps and single-page web apps outside of a firewall need accessible endpoints to function.
These are clearly publicly visible. However, there is no law that says you need to document them publicly or support them for other than your own internal purposes.
They may be hard to lock down.
If your users need to have an account, you can choose to reject unauthenticated API calls as appropriate. (Think about gmail - what could you do if you were not logged in?) This is not bullet-proof though - an otherwise legit user with credentials could potentially write their own application against your API and your API won't be able to tell it isn't your app calling (assuming the calling application wishes it that way - emulating valid user agent and referred headers for example).
There are some measures you can take to discourage casual or unintended use of your
API. You can check http headers for user agent (is this really iOS device?) and
referrer (is this really coming from page from my web app?) or even add a custom HTTP header (X-MyCompany-InternalUseOnly). If any of these are not as expected, your API could return something different -
for example "this is an internal use only API" message. You could also
use SSL to complicate discovery of how the API works.
But none of these are
bullet-proof in the face of a motivated hacker; I'm not sure it is possible to really lock down an API that needs to be publicly visible and available to unknown clients.
-Bill