At a conference a few days ago, I put up a slide with a few of my favourite tools on it. I got some brilliant additional recommendations in return from twitter so I thought I'd collect them all in one place in case anyone is interested - all these tools are excellent for anyone working APIs (so that's everyone!). First, my original slide:
HTTP for Web Developers
Slim framework has recently invaded my life, I picked it up for a hobby project, recommended it to a client who then contracted me to do quite a lot more development, and it's also used for m.joind.in. One thing that has tripped me up a couple of times is how to return not-HTML from Slim as it just bins any headers you try to send yourself. I think also that the "right" way to do this may have changed between versions as I also found some examples that didn't work! What did work for me was this:
$app variable is the Slim\Slim instance for your application, once you have that, you can just add on any headers you need to with this call to
header(). It wasn't obvious to me and there weren't a lot of resources for this, so I thought I'd share!
In case you missed it, Twitter updated their APIs recently, so that you have to authenticate to use even their search APIs to return publicly-available results. This is an increasing trend for API providers, to provide either very limited or nonexistent access for unauthenticated users, I think so they can rate limit consumers that swamp them. To cut a long story short, that meant I needed to update my dashboards that keep an eye on twitter searches to do more than just call
file_get_contents in the general direction of the right URL. Continue reading
Last week I tried to create a PHP stream context which set multiple headers; an Authorization header and a Content-Type header. All the examples I could find showed headers built up as a string with newlines added manually, which seemed pretty clunky and not-streams-like to me.
In fact, you've been able to pass this as an array since PHP 5.2.10, so to set multiple headers in the stream context, I just used this:
<?php $options = ["http" => [ "method" => "POST", "header" => ["Authorization: token " . $access_token, "Content-Type: application/json"], "content" => $data ]]; $context = stream_context_create($options);
$access_token had been set elsewhere (in fact I usually put credentials in a separate file and exclude it from source control in an effort not to spread my access credentials further than I mean to!), and
$data is already encoded as JSON. For completeness, you can make the POST request like this:
Today's quick tip is something that was widely retweeted after my "Debugging HTTP" talk at the ever-fabulous WhiskyWeb conference last weekend. When working with JSON on the commandline, here's a quick tip for showing the JSON in a nicer format:
curl http://api.joind.in | python -mjson.tool
You need python installed, but the JSON extension is probably included, and that's all you need for this tool. The result is something like:
You can also use this approach to present JSON data that has been captured to another file, for example, it's a handy trick that I use often when developing something with JSON as a data format.
While working on a book ("PHP Web Services" from O'Reilly, not out yet but soon!) recently, I was looking for some place I could make HTTP requests to, to show off how to make different kinds of requests with different tools. On my own machine, I have a couple of scripts that chatter back giving debug information about the requests that were made, but I wanted to get the tools examples going without any additional dependencies at all. I hadn't used anything like these tools before, but I found quite a few alternatives, so I thought I'd share what I came up with. Continue reading
Yesterday, I saw this tweet:
I have lots of advice for Olly (whom I know personally) but there's no way it will fit into a tweet! So here it is, in rather longer form :)
I'm working on an API which uses OAuth2, but it also has an HTML output handler so I actually do quite a lot of my development in the browser for read-only stuff (I wrote an earlier article about output handlers including the HTML output handler). I fell across an extension for Chrome called ModHeader (WTF kind of URL is that, google?) which does this trick for me!
Once I have the access token, I add the Authorization header using ModHeader and it sends it on all requests to this API, so I can still use my HTML output handler and be logged in. It's useful for sending custom headers of all kinds for different tools, so I thought I'd mention it!
Once upon a time, what seems like a lifetime ago, I was away for a couple of weeks, and I wrote a series of posts about serving RESTful APIs from PHP to keep my blog going while I was away. Fast forward a few years and those posts are outdated and still wildly popular - so I thought it was about time I revisited this and showed how I'm writing RESTful PHP servers today!
In the first part of this (probably) 3-part series, we'll begin with the basics. It might seem boring, but the most important thing to get right with REST is parsing all the various elements of the HTTP request and responding accordingly. I've put in code samples from from a small-scale toy project I created to make me think about the steps involved (should I put the code somewhere so you can see it? Let me know). Without further ado, let's dive in and begin by sending all requests through one bootstrap script: Continue reading