That's a fine way of doing things. Here's an overview of the requirements and components play in your security scheme:
Checklist
Here's the checklist of what security is needed, and how you would address it:
- A third party can't eavesdrop on your communications. HTTPS provides this.
- A third party can't tamper with your communications. HTTPS provides this too.
- The client can authenticate the server. HTTPS provides this (*).
- The server can authenticate the client.
Client authentication
There are lots of way to authenticate the client. Here are a few exaples:
- Use the API key to calculate an HMAC of the request and include the HMAC as a header in the request. (**) The most secure, but more complicated to set-up. The key advantage is that should your server be compromised, API keys won't be exposed.
- Include the API key itself in the request. Easier to set-up, may be sufficient security depending on your requirements.
- ...
(*): So long as the client library does. HTTPS requires that you use a certificate that validates your site corresponds to the domain name. Unfortunately, many HTTPS libraries do not validate this by default.
(**): You should also use a nonce to prevent against replay attacks.