Did you know that PHP’s
http_build_query() drops any key from your query array if the value is
NULL? I wonder how many subtle API client bugs are caused by this behavior.
The workaround is easy, just set values that should be intentionally empty to boolean
FALSE, integer 0, or an empty string.
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
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)
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.
- 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
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.
- 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.
- 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).