The point of difference between using HTTP Authentication vs Application specific authentication is where you want the authentication and authorization logic to be handled.
HTTP Authentication means that the HTTP layer (apache, nginx, IIS, etc) will responsible for maintaining authentication. Application authorization means that the web application (java, php, django, etc) would control authentication and authorization.
Why the difference?
Remember that HTTP is stateless. Thus, by adding an authorization component, HTTP can prevent or allow users to access certain resources. The most likely use of this kind of authorization is when you don't have any application logic yourself. For example, if you want to allow file directory browsing in apache, but only to certain users, you can modify the .htaccess file to restrict the directory to certain users.
However there are many reasons why applications handle the authorization logic instead of the HTTP server. First, most applications handle sessions. This is done by using cookies. Thus, only the cookie value must be retransmitted. If you are handling sessions in the application layer, it will almost always be easier to handle authorization in this layer as well. Almost always, sessions are preferred because the content of your application will be dependent on "who" is doing something.
But my application can read the HTTP Headers, why use forms if HTTP provides a mechanism?
A further benefit to using sessions includes the implicit ability to log out. Because HTTP authorization has no concept of a session, you can't really log out. It would be up to the browser (or in your case, the Android application) to forget the credentials, but the server has no control over it. Even if your server wants to enforce some kind of log out, it can't with HTTP Authorization.
Security benefits of form based authentication
Because form based authentication generally involves sessions, it is usually more secure, so long as the security of your resources are dependent on sessions.
Security benefits of HTTP Authentication
HTTP Basic authentication is worse than forms based authentication because of the lack of sessions. However, you can get some benefits by using HTTP Digest Authentication, which computes hashes against credentials and nonces to avoid sending plain text credentials. Thus there is a tradeoff between sending clear credentials or letting the server side application maintain the session.
Can't I compute hashes on the client side before transmitting the credentials?
For browser based applications, many people think using javascript to compute a hash before sending a credential is better than using a plain text password, but these people are wrong. In order to protect the password, the server sends client code that it must run. However, if an attacker is in a position to talk to the client, he can substitute this code for his own. Thus, the security benefit of using javascript to compute a hash is so minimal it is rarely done.
Since you mentioned using this API within an Android Application, hashing does make sense. Because you can compute the hash with a predefined client routine, there are clear benefits to using a hashing mechanism as described in RFC 2607. I would still recommend performing authorization in the application layer though, as you want to manage sessions for a user.
