I agree with the list and I would like to add a couple of points to it. 1. don't return error formats in a different data format (e.g. xml error response with

I agree with the list and I would like to add a couple of points to it. 1. don't return error formats in a different data format (e.g. xml error response with a json api) 2. don't use custom request signing (hey, mixpanel and seomoz) 3. when rate limiting, use headers to communicate how much requests are left, how many were made before and how many seconds until the rate is refreshed. 4. Authentication, there's an obvious ease-of-use vs. sensitivity of the data. but when in doubt pick basic auth (or api-token) with https and close port 80 on the api host. 5. use REST 6. be fast 7. provide as much nested data as you can without violating 6 8. maintain your own client libraries I agree with the comments here that documentation and consistency is a good thing, I also agree with having an option to batch requests if you have a rate-limit in-place.