The Zemanta API is quite a simple API at this point, but it works nicely. To give some background, you feed the API with a text, Zemanta analyses this text, and offers links, images and tags as a suggestion for usage with the text. Excellent for weblogs and magazines looking to enrich their content. The API call therefore is nothing more than a POST request that requires a few parameters: text, return format, method (currently simply zemanta.suggest) and an API key. Should not be too hard, you’d think?

Think again
Since it’s a simple request, I immediately decided to use the already installed sfWebBrowserPlugin for this request. It has a very simple API, and should work fine. However, I couldn’t get it to work correctly. I kept getting a 403 Developer Inactive error. A weird error, which led me to believe I might be using an incorrect API key. I double checked it with the key in my control panel, but nope, everything was correct.

I need a second opinion
I wasn’t making any progress, so on to the next attempt: Use another tool to do the same thing. I decided to dust off my Zend_Http_Client knowledge and use that instead. After 10 minutes of work (well, mostly reading into the exact syntax of doing the call) I had a working example. Including a valid response. So no problem on the Zemanta side, the developer was active! It was something in symfony or the plugin.

Let’s squash that bug
I couldn’t have it that something worked fine in Zend Framework, but wouldn’t work in my beloved symfony. So I started trying other things, trying to chase the parameters sent with the request, but all seemed fine. After looks of searching through the code, trying the different adapters that come with sfWebBrowserPlugin, and comparing the approach of sfWebBrowserPlugin with the approach of Zend_Http_Client, I noticed one thing: the call to http_build_query() was different.

sfCurlAdapter was calling http_build_query($parameters) where Zend_Http_Client was calling http_build_query($this->paramsPost, ”, ‘&’ ). Notice the two extra parameters, of which the second is the most important in this situation. It turns out if you leave the seperator parameter empty, it defaults to the encoded &, which clearly the Zemanta API at least could not handle (and perhaps others as well). When I changed the call to http_build_query($parameters, null, ‘&’ ), the problem was solved! I got back the expected XML response using the sfWebBrowserPlugin.

Contribute!
As I’d suggest every Open Source user to do, I immediately opened a bug for this so that it can be fixed by the developer of the plugin. Contributing back fixes like these to the project helps all users, and eventually makes the project so much better

Update!
It seems I have been stupid all along. The bug was already fixed in the sfWebBrowserPlugin a long time ago. I installed the plugin a long time ago into my project and never since updated it to the latest version, not even when encountering this bug. My bad, sorry Francois! 🙂