Under an open API, absolutely no security or authentication methods are used. A query is received from the wild, and the system makes its best effort to respond to it appropriately. This has several advantages and disadvantages.

Advantages:

• Absolute minimum barrier to use — By not using encryption or special authentication methods, anyone with access to the Internet should be able to begin working with your API quickly.

• Easily distributed code — Login accounts or developer key programs that make use of your API can be widely distributed and used right out of the box.

• Less to worry about — If you aren't managing user accounts or development keys, it's one less thing to keep track of, and your code efforts can concentrate solely on developing the API itself.

Disadvantages:

• No control — Anyone, anywhere, can use the API, and while this may sound like the goal of web services, it drastically limits your response if abuse requests begin pouring in. If those requests are coming from an application on a single machine, it is easy enough to recognize the requests and block them at the firewall. But should an application that behaves poorly reach wide distribution, you will have a very difficult time dealing with the requests.

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

• Can't contact developers — Because anyone anywhere can access the API without any prior registration, you are left without any method of directly engaging developers using the API. You may want to contact developers in situations where their application is being abusive, when changes are being made to the API that will affect their application, or to seek suggestions on how to improve the API itself.

• Abuse — Unfortunately today, systems with little or no security or authentication make prime targets for abuse by some less ethical elements out there. Even if you feel that the risk is minimal, you may end up surprised at what others can take advantage of.

With those elements in mind, the only situations in which a completely open API would be appropriate are ones where the API is used only to request information, never to publish it, and where the information being requested is generated (or cached) in a very CPU nonintensive manner. A perfect example would be the National Weather Service API. It only accepts requests for information, and those requests are easily cached for a full hour on the server. In cases where the API allows information to be pushed to it, some authentication is required to determine who is pushing the information, and when requests can be CPU-intensive, the remote application needs to be identifiable so incoming requests can be throttled if necessary.