I had a chance to work with SiteImprove’s API recently, and wanted to capture my thoughts and impressions while they were still fresh in mind.
First, the documentation was above average. Once you’ve received your API key, you can literally “test drive” particular methods within the documentation, right below the area where that particular method is explained. You see everything, the response, the headers, etc. which comes in handy when you’re troubleshooting an issue.
Second, the “next page link” being included in the results when the amount of matching items exceeds the amount per page (defaults at 10, can be maxed out at 1000). Makes recursive requests dead simple– if the “next link” exists, drop it in as your url variable’s next value, and let your for loop continue. If the “next link” doesn’t exist, break out of your loop. And the “next link” already has the correct url attributes appended to it, so you don’t need to worry about updating it or dealing with page number and items per page in your code.
Ok, so what did I *not* like? SiteImprove uses header responses to convey information about your current rate limit (e.g. 50), how many requests you have remaining (e.g. 25) and the rate reset (e.g. 5 seconds). That’s right: integer, integer, string? Why they didn’t keep the last one an integer and opt for milliseconds (e.g. 5000) is beyond me. But if slicing off the text and converting the result to milliseconds for a sleep() interval is the worst thing I have to complain about, that’s pretty good overall.
If you’re using this to retrieve JSON:
And find your response is JSON wrapped in a bare-bones HTML document, rather than just the JSON you were expecting, you might need to add a cfhttpparam accept tag to specifically reference application/json, like so:
<cfhttpparam type="header" name="Accept" value="application/json">
I spent more time than I’d have liked last week fixing an issue related to the intermittently incorrect appending of UTM parameters to URLs. Basically, the code worked fine if the link was “basic”, but if it already had parameters, a second question mark would get added. Since URLs cannot have two question marks, the link would break.
I hope you’ll find this useful– both in the sense of finishing a coding task faster, and having fewer issues to resolve after deployment.