Good practices when building with Twitter APIs

Over the past few months, I’ve received a handful of similar questions from our developer community at events, via Tweets, and within our developer forums.  I’d like to share a few good development practices that I’ve found to be helpful to others.

Use twurl to quickly test your implementation

I love twurl. It’s a tool written in Ruby that enables you to quickly poke the API for data, and try out query syntax. I use it daily to verify bug reports and to help to validate test cases submitted via our developer forums. Using twurl you can test individual endpoints and queries and check for responses. As it’s a command-line tool, you can chain it with handy JSON utilities like jq (to format responses in a pretty manner), and query or reformat responses.

You’ll find a Gist with a bunch of example twurl queries here, to give you a feel for how powerful it is.

Understand the rate limits on our standard APIs

The standard (free and public) APIs include an endpoint that lets you check for the Twitter configuration values, and another that provides a set of common rate limits. However, rather than constantly querying those, the best way to keep up with how your application is performing in real-time is to check the headers on HTTP responses per API call (you can see these using the -t option when using twurl, for example).

When you do this, look for x-rate-limit-limit, x-rate-limit-remaining, and x-rate-limit-reset. Also, don’t forget that read (GET) endpoints provide this information, but write (POST / DELETE) endpoints are bound to Twitter’s user account limits, and are treated differently by the limiter front-end.

To learn more, read through the documentation.

Build your app for flexible data objects

To provide the best experience for your users, be sure you’ve built your applications so that they do not include hard-coded length assumptions for the JSON payload or the Tweet display. With the latest experiments, the display range for some Tweets may extend beyond 140 characters.

We’ve designed the Tweet payload and most recent experiments to minimize impact to your systems, so that they’ll continue to function without breaking. However, if you have chosen to hard-code assumptions about the lengths of Twitter objects or the values inside them, you may only receive partial JSON payloads. In this case, your displays may not properly show a full Tweet, or you may miss some of the content of the extended entities.

For more guidance here, I recommend taking a look at our technical resources.

Fail gracefully, back off exponentially

The standard APIs are not always 100% reliable, but aim to be eventually consistent. Especially in times of particular load, you may experience interruption. If you see an error code from the API, wait a bit before retrying your query. This gives the backend service that your query is hitting some time to either fail across to another instance, or to recover.

If you need higher levels of reliability, the enterprise APIs provide (optional) redundant connections, and replay options.

Additionally, look for an updated and improved API status page that provides more insight into the performance of the platform coming very soon to developer.twitter.com.

Keeping up-to-date

We’ll continue to post tips and guidance to this blog over time. Look out for upcoming guides and tutorials on the refreshed developer.twitter.com.

Don’t forget to talk to us in the developer forums, share useful tips of your own with other coders, and let us know what you’d like to see next. It’s a great time to build apps on the Twitter Developer Platform, and I’m excited to be on this journey with you.