HTTP Basic Authentication is not much used in browser-server connections because it involves, on the browser side, a browser-controlled login popup which is invariably ugly. This of course does not apply to server-server connections, where there is no human user to observe any ugliness, but it contributes to a general climate of mistrust and disuse for Basic Authentication.
Also, in the 1990s, before the days of SSL, sending plaintext passwords over the wire was considered a shooting offence, and, in their folly, people considered that challenge-response protocols like HTTP Digest were sufficient to ensure security. We now know that it is not so; regardless of the authentication method, the complete traffic must be at least cryptographically linked to the authentication to avoid hijack by active attackers. So SSL is required. But when SSL is in force, sending the password "as is" in the SSL tunnel is fine. So, to sum up, Basic Authentication in SSL is strong enough for serious purposes, including nuclear launch codes, and even money-related matters.
One should still point out that security relies on the impossibility of Man-in-the-Middle attacks which, in the case of SSL (as is commonly used) relies on the server's certificate. The SSL client (another server in your case) MUST validate the SSL server's certificate with great care, including checking revocation status by downloading appropriate CRL. Otherwise, if the client is redirected to a fake server, the fake server owner will learn the password... In that sense, using something like HTTP Digest adds some extra layer of mitigation in case the situation got already quite rotten, because even with HTTP Digest, a fake server doing a MitM can still hijack the connection at any point.
If we go a bit further, we may note that when using password-based authentication, we actually want password-based mutual authentication. Ideally, the SSL client and the SSL server should authenticate each other based on their knowledge of the shared password. Certificates are there an unneeded complication; theoretically, SSL client and server should use TLS-PSK or TLS-SRP in that situation, and avoid all the X.509 certificate business altogether.
In particular, in SRP, what the server stores is not the password itself but a derivative thereof (a hash with some extra mathematical structure). One shall note an important point: in the case of a Web API, both the client and the server are machines with no human involved. Therefore, the "password" does not need to be weak enough to be remembered by the meat bags. That password could be, say, a sequence of 25 random characters, with an entropy gone through the roof. This makes the usual password hashing methods (slow hashing, salts) kind of useless. We still want to avoid storing in the server's database (thus as a prey to potential SQL injections) the passwords "as is", but, in that case, a simple hash would be enough.
This points to the following: ideally, for a RESTful API to be used by one server to talk to another, with authentication based on a shared (fat) secret, the communication shall use TLS with SRP. No certificate, only hashes stored on the server. No need for HTTP Basic Auth or any other HTTP-based authentication, because all the work would have already occurred on the SSL/TLS level.
Unfortunately, the current state of deployment of SRP-able SSL/TLS implementations usually means that you cannot use SRP yet. Instead, you will have to use a more mundane SSL/TLS with an X.509 certificate on the server side, that the client dutifully validates. As long as the validation is done properly, there is no problem in sending the password "as is", e.g. as part of HTTP Basic Authentication.
