Client credentials can also be passed along with the regular message payload. This is marginally easier to implement on the client side because adding credentials should be no more difficult than adding another parameter to the request. Remember that even if a secure (SSL) endpoint is used, the URL used for the request is still sent in the clear, so if the credentials are passed on the URL (as is the case with a REST request), they will be visible to any and all intermediaries.

Advantages:

• Easily handled — Authentication should be checked before any other processing, just like a regular page.

• Easy to code — Programmers who wish to access the API need only add an additional parameter.

• Easy to track — Configuring your application to track how many calls during a certain time period, and throttle if necessary, should be easy.

Disadvantages:

• Credentials in the clear — REST APIs will have their credentials sent in the clear whether or not a secure endpoint is used. Nonsecure endpoints will have credentials sent in the clear for both REST and SOAP APIs.

• No encryption — All requests and responses are visible to anyone between the requesting server and the API server.

Message-based authentication is very similar to HTTP authentication in the level of security it provides, the primary difference being the pass off from handling the authentication from the web server to the API application itself. As with HTTP authentication, the API's authentication should be separate from authentication used elsewhere on the site.