Q:

RESTful API database authentication, which verb?

I need an API call to authenticate a login. We have a database with a users table, and we're building a front-end, with an API in the middle. The front-end takes a username and password from the user, and we need to authenticate these credentials against the database using the API.
So we have:

Request to authenticate the user
Response to indicate authenticated or not

Request
I'm guessing the request should be a GET, as POST is for creating and PUT is for updating, and we're doing neither of those.
We need to send the username and password to the server, and since we're using GET, am I correct in saying we can only use query string parameters or headers to send the data..?
I don't think query string parameters is right for passwords etc, so that leaves headers for the request:
GET https://my-local-api-server/authenticate HTTP/1.1
username: my.username
password: mypassword

Is this a correct RESTful request, sending data to the server for authenticating..?
Response
For the response, should we only use the response status code (200 or 401), or should we send JSON containing the outcome of the authentication request..?
{
    "authenticated": true,
    "error": ""
}

or
{
    "authenticated": false,
    "error": "Some error message..."
}

Which is the correct RESTful response..? Or should it be both..?
UPDATE
My question wasn't great, so I need to clarify.
I shouldn't have used a public URL in my example above, this is actually a local server and local API, which will never be used externally, and will only be consumed by other local apps internally. If this ever changes we can revisit what we're doing.
I think I confused things a bit by not being clear about the authentication I'm doing. I'm authenticating a user (a real world person) against a database. I'm not authenticating the usage of the API.
The apps we're going to be writing are all internal and won't need to authenticate to use the API. No API keys etc. 
So... I'm taking a real world person, and checking to see if they should have access to our app, I'm not checking to see if our app has access to the API.

A:

An overview of authentication in REST
In REST APIs, when accessing protected resources that require authentication, every request must contain all necessary data to be properly authenticated/authorized. And authentication data (credentials) should belong to the standard HTTP Authorization header:

4.2.  Authorization
The Authorization header field allows a user agent to authenticate
  itself with an origin server -- usually, but not necessarily, after
  receiving a 401 (Unauthorized) response.  Its value consists of
  credentials containing the authentication information of the user
  agent for the realm of the resource being requested. 
Authorization = credentials

[...]

Please note that the name of this HTTP header is unfortunate because it carries authentication data instead of authorization. Anyways, this is the standard header for sending credentials in the HTTP protocol.
REST applications are supposed to be stateless, so there must not be session state stored on server side. Instead, the session state must be handled entirely by the client, as defined in the Roy T. Fielding's dissertation about REST:

5.1.3 Stateless
[...] each request from client to server must contain all of the information necessary to understand the request, and cannot take advantage of any stored context on the server. Session state is therefore kept entirely on the client. [...]

Hence, it doesn't matter the verb you are using, if you are performing a request to a protected resource, the request should contain the authentication data.
Basic authentication
A common approach for securing REST APIs is to use the Basic Authentication Scheme:

2. The 'Basic' Authentication Scheme
The Basic authentication scheme is based on the model that the client
  needs to authenticate itself with a user-id and a password for each
  protection space ("realm"). [...] The server will service the request only if it can validate
  the user-id and password for the protection space applying to the
  requested resource.
[...]
To receive authorization, the client

obtains the user-id and password from the user,
constructs the user-pass by concatenating the user-id, a single
  colon (":") character, and the password,
encodes the user-pass into an octet sequence,
and obtains the basic-credentials by encoding this octet sequence
  using Base64 into a sequence of US-ASCII
  characters.

[...]
If the user agent wishes to send the user-id "Aladdin" and password
  "open sesame", it would use the following header field:
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

[...]

Token based authentication
Another approach that is taking place is token based authentication. In this approach, you basically exchange hard credentials (username and password) for a token that the client must send in every request. In this approach, you can used POST to perform the authentication, sending the credentials in the request payload:
POST /api/authentication HTTP/1.1
Host: example.com
Content-Type: application/json

{
    "username": "username",
    "password": "password"
}

If the authentication was successful, return a 200 status code along with a token in the response payload:
HTTP/1.1 200 OK
Content-Type: application/json

{
    "authenticationToken": "<token goes here>"
}

Otherwise, if the credentials are invalid, return a 401. 
It's important to note that tokens are the credentials that will be used to authenticate the subsequent requests. So, tokens should be sent in the Authorization header too:
Authorization: Bearer <token goes here>

