Consuming APIs is something most developers--and even some non-developers--are doing most of the time. It's becoming more common to build an API, in addition to using them. For all of those of you who are just getting your feet wet with this process, data portability service Gnip has shared a few pointers to keep you on the straight and narrow.
- Use Standard HTTP Response Codes
- Publish Your Rate Limits
- Use Friendly Ids, Not System Ids
- Allow Us to Limit Response Data
- Keep Your Docs Up to Date
- Publish Your Search Parameter Constraints
- Use Your Mailing List
One rule of thumb that stands out is to use standard response codes. It's so easy to forget that sometimes there's a HTTP response code that could be used in place of an in-content message. This can save bandwidth and is more standards-compliant, and therefore more predictable to code against.
And there's a really important note too about keeping documentation up to date. It's so important that it's a matter of life and death (of your API). So, try to stay on top of the docs and read our Web API Documentation Best Practices.
You'll be able to build a much happier community around your tools if you provide them with a clear set of instructions and an open channel of positive communication. This will definitely get you the thumbs-up from other developers. And don't forget: a happy community is a vocal one!
Be sure to read Gnip's entire list, which includes additional information about each guideline.
Photo by joeltelling