Tag Archives: API

Disqus guest posting via API

While evaluating the Disqus API for things like posting and flagging as a guest, I was baffled by this non-descript error:

{"code":12,"response":"This application cannot create posts on the chosen forum"}

After checking the obvious things (like enabling guest posting and checking my domain settings for my forum and application), I was finally able to solve this using the disqus-php library:

require __DIR__ . '/disqus-php-master/disqusapi/disqusapi.php';

$disqus = new DisqusAPI($secret_key);

    'thread' => $thread_id,
    'message' => $message,
    'author_name' => $author_name,
    'author_email' => $author_email,
    'api_key' => $api_key,

The catch is that the api_key is NOT the same thing as the public key shown in your Disqus application settings. I actually had to inspect one of the AJAX calls from the Disqus Javascript widget to get the correct api_key:

Disqus AJAX call headers showing the api_key

Heartbeat logging while consuming Twitter streams using Phirehose

Phirehose is an awesomely useful Twitter Streaming API client library, written in PHP by Fenn Bailey.

Heartbeat logging is something that I originally added for Rainmaker, and I finally got around to contributing those modifications, which you can see here on GitHub.

Why log heartbeats in Phirehose?

  • To gain assurance that Phirehose is still alive, and actually functioning. In our case, missing tweets means lost money and unhappy clients. We needed to monitor this very closely.
  • To enable automatically detecting connection drops and rewinding the count parameter to pick up those tweets, or backfilling them in using the Twitter Search API.
  • To collect usage data for reporting purposes.


To use this, simply declare a heartbeat(array $data) method in your Phirehose child class. Continue reading

Takeaways from PHPCon, day 1

I’m here at PHPCon, the first PHP community developer conference in Nashville, TN. The first day consisted of two rather lengthy workshops, both of which were very informative.

Download my notes (PDF)

Web Services

This talk was given by Lorna Jane Mitchell, whose totally awesome British accent I could listen to all day. I consider myself no novice on consuming web services, but being a relative newcomer to building web services, I got a real education on how to do it right.

Key takeaways:

  • Use curl, it eliminates points of failure for more accurate testing. Lorna rejects any bug ticket that does not come with a curl test case, which reduced support requests by 50%!
  • Every web service should have a heartbeat method that echos the variables you pass to it.
  • Every web service should have documentation, (real) examples, and a support mechanism. If you’re not going to do this, don’t bother building a web service, ’cause nobody’s gonna use it.
  • Utilize the HTTP protocol as fully as possible, including HTTP headers (Accept, Content-Type, User-Agent), verbs (GET [read], POST [create], PUT [update], DELETE [delete]), and status codes (HTTP 200, 201, 301, 302, 400, 401, 403, 404, and 500).
  • Give consumers a choice of formats. text/html is useful for debugging purposes.
  • Parse the Http-Accept header and deliver content in first format listed that you support.
  • Don’t confuse HTTP 401 with HTTP 403 (“I don’t know who you are, so I’m denying access” vs “I know who you are, and you don’t have permission”).
  • pecl_http is an easier way to access web services than curl.
  • Error handling defines API quality. Provide complete, useful, and consistent error messages in the expected response format.

Link bundle: http://bit.ly/bundles/lornajane/2

Frontend Caching

This talk was given by Helgi Þorbjörnsson (I will not even attempt his Icelandic surname). Helgi is a long-time PEAR contributor and experienced front-end developer. Key takeaways:

  • 80% of response time is spent downloading resources.
  • Don’t abuse cookies. Large cookies hurt performance because of slow upload speeds, and because they are sent with every request. When you use cookies, be sure to set an expiration date and limit them to only the domains they are needed on.
  • Browsers have per-domain concurrent download limits. You can spread static assets across 3-4 multiple subdomains as a workaround.
  • Combine files judiciously. Be aware of the trade-off between fewer server requests and larger file size.
  • Load above the fold first.
  • Minify Javascript and CSS, preferably at build time.
  • Use gzip compressiononly for text-based content.
  • Save HTTP 404 bandwidth by ensuring that you have a robots.txt file and a favicon.
  • Compress images more (Photoshop doesn’t cut it; better alternatives include pngcrush and jpegtran).
  • Test with slower connections (tread the user’s path).