Configuring your web server to present the API over an SSL connection adds protection for both the request and response bodies, while requiring little to no additional coding for the API. Remember that the use of a server certificate only authenticates the server for the client, it does nothing to identify the client itself. It is best used layered with one of the previous two examples.

Advantages:

• Encryption — Both request and response bodies are protected from intermediate prying eyes.

• Server authenticated — Clients who record the server's SSL certificate can monitor it to ensure it does not change over time (which could indicate a man-in-the-middle attack). Using a certificate signed by a signing authority can also provide a similar level of assurance for the client application.

• Easy setup — No additional coding required, just configure the web server.

Disadvantages:

• Increased load — Encrypting and decrypting communications is noticeably more CPU-intensive than unencrypted communications. Every request requires additional back and forth communications to set up the secure socket.

• No client identification — Using an SSL

• Additional client-side requirements — Handling SSL from the client side isn't always trivial, and languages may require additional extensions installed (which may or may not be available in a shared host environment).

SSL is an excellent layer to add to any API. It provides security for the request and response payloads, as well as provides some assurance for the client application as to the identity of the server. It is easily combined with either HTTP authentication or message-based authentication. Some care, however, should be taken not to use SSL unnecessarily, because it has additional requirements for the client application that not all developers may be able to meet, and it places additional CPU load on both sides as messages are encrypted and decrypted.