answer:You should start by defining what kind of data and methods you want to expose. Then you’ll want to decide how the API is accessed including authentication. Most often, data is exposed with XML. There are some existing standards out there such as XML-RPC (which is a much more manageable than SOAP). Of course, there’s nothing wrong with rolling your own format if you want to keep things simple. Most of the time when exposing methods that don’t return data you’ll want to return some sort of response indicating the success or failure of the request. I’ve seen many APIs that always return a standard response with the data that may or may not be returned by it wrapped inside the response. The utility here is that you can always expect some kind of standard response for each request. Determining how the API is accessed is something to put thought in to as well. Most APIs out there, though, receive requests via HTTP POST. Some places use a namespace style of naming their methods (eg. “news.create”, “friends.jellies.getAll”) but whatever you decide is ultimately not going to be a big problem for anyone accessing it (just be sure to document it!) Finally, when it comes to authentication it is a matter of your desire for security. It is possible that you won’t need authentication but if you are creating a system where you have users or access tiers then you’ll need something. One of the more effective methods is an access token exchange where the client requests an access token from your API by supplying an ID and a secret of some sort (password). If these credentials are valid, your system then creates a token that is good for a certain period of time and you return it to the client. When the client makes requests to the API, the token is expected and you need only validate it and check for its expiration. I’d suggest taking a look at some APIs out there right now to get a feel for their operation. Check out Flickr, any of Google’s APIs (these are well designed in my opinion) or maybe Twitter. Hope that helps.