Many recent API styles (REST, SOAP) are built on HTTP. The justification for this is that it traverses proxies and firewalls and provides pre-built security functionality.

In my opinion, this is a bad idea. HTTP is not an RPC protocol or any other kind of API protocol; it's a document retrieval protocol, and has very limited security support. Standard well-supported RPC protocols do exist (think Apache Thrift), and they provide security at or above the level that HTTP does. In addition, proxy traversal is not always good; some proxies modify requests and responses. In some cases it might be better for a request to fail than to be delivered in a potentially-corrupted state. Using a proper RPC protocol provides several advantages over HTTP:

In summary, using HTTP as an API transport is misuse of a protocol where better alternatives are available and causes numerous problems. Using a proper RPC protocol like Thrift provides a number of advantages.