Depends on the right combination of usefulness and simplicity. I'm assuming this is web-based. Here's something practical at the implementation level: 1. It d

Depends on the right combination of usefulness and simplicity. I'm assuming this is web-based. Here's something practical at the implementation level: 1. It doesn't have to be true REST-ful. But it should be as easy as forming a GET URL string, or if appropriate, POST with simple, string payloads unless it is binary data like images etc. i.e. no XML attachments please. Twitter, Posterous are good examples of these. 2. Return results in JSON and XML. Prefer JSON. It is easier and more efficient (yes, it's a hunch, no benchmark done) to get a dictionary/hashmap from a JSON string rather than XML. And the quickest way if I want to use such an API quickly and easily is to load the results into a dictionary/hashmap and grab values from there. Twitter is good here. 3. If you provide the API with results in more than 1 format make sure they work the same. The Twitter API is a great example of what your API should not be. 4. Make sure they work. At least fix them quickly, this is a web-based API, and web-based means they can be fixed quickly. The Twitter API is a great example of what your API should not be. 5. Give developers enough time and warning when you make breaking changes. The Twitter API is an example of what it should not be. Posterous is a great example of what it should be. 6. Don't make me get a developer key/ID please. 7. Versioning. Don't bother. Yet.