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.
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.
Web Services Tutorial </p>
View more presentations from Lorna Mitchell
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).
Written on April 21, 2011