This is the third installment in my series about writing a RESTful web service in PHP (the previous entries are about understanding the request and routing it. It is probably the last one but there are a few other things I'd like to cover such as error handling, so I might keep adding to it, especially if I get any particular requests or interesting questions in the comments. So far we've covered parsing requests to determine exactly what the user is asking for, and also looked at routing to a controller to obtain the data or perform the action required. This post gives examples of how to return the data to the client in a good way. Continue reading
One of the big features arriving with PHP 5.4 is the addition of a built-in basic webserver for use in development environments. Quite a few of the other scripting languages have something like this so I'm very pleased to see it in PHP. Using a server like this makes it easy to quickly try out some scripts without needing to configure apache or really do anything much! I had to look up a few things to get started, so I thought I'd write them down for posterity. Continue reading
This is the second part of a series, showing how you might write a RESTful API using PHP. This part covers the routing, autoloading, and controller code for the service, and follows on from the first installment which showed how to parse the incoming request to get all the information you need.
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
I've been working with OAuth, as a provider and consumer, and there isn't a lot of documentation around it for PHP at the moment so I thought I'd share my experience in this series of articles. This relates to the stable OAuth 1.0a spec, however OAuth2 has already started to be adopted (and differs greatly). This article uses the pecl_oauth extension and builds on Rasmus' OAuth Provider post. This entry follows on from the ones about the initial requirements, how to how to handle request tokens, and authenticating users.
My interest was mostly because I'm working on a book chapter which includes some static analysis content, and there are a couple of these tools that I include in my own builds, but I don't do much with the output of them. However I didn't want to drop anything from the chapter if it was actually a valuable tool and I was just missing the point - pretty much all the tools got a good number of votes though, so I'll be covering all of the above. It does look as if phploc has less of a following, however it's one of my favourite tools so it gets a mention anyway!
Thanks to everyone who took the time to vote; I thought I'd share the results in case anyone was interested.
I've been looking around for a really simple API that would be a nice place to get started using web services from PHP - and I realised that bit.ly actually fits the bill really well. They have straightforward api docs on google code, and it's also a pretty simple function!
Here's a simple example, using PHP's curl extension, of using the bit.ly API to get a short URL, using PHP (you need an API key, but if you're a registered bit.ly user, you can log in and then find yours at http://bitly.com/a/your_api_key).
$ch = curl_init('http://api.bitly.com/v3/shorten?login=username&apiKey=R_secret&longUrl=http%3A%2F%2Flornajane.net'); curl_setopt($ch, CURLOPT_RETURNTRANSFER, true); $result = curl_exec($ch); print_r(json_decode($result));
When I wrote about launching a prototype of a new joind.in API, quite a few people started to try it out. My friend David Soria Parra emailed me to point out that many of the numbers in the API were being returned as strings. He said:
It's just a standard problem of PHP REST services. When I try to access it with java I have to convert it over and over again to ints.
I did have a quick look at the PHP manual page for json_encode but I didn't see anything mentioning this. A few weeks later (my inbox is a black hole and it takes a while to process these things) I fell over a throwaway comment to an undocumented constant JSON_NUMERIC_CHECK, and I added the constant name to my todo list. In the time it took for me to actually get around to googling for this, some wonderful person updated the PHP manual page (this is why I love PHP) to include it as a documented option, and someone else had added a user contributed note about using it.
It turns out, this constant does exactly what I need. Here's a simple use case:
echo json_encode(array('event_id' => '603')); echo json_encode(array('event_id' => '603'), JSON_NUMERIC_CHECK);
and the output:
There are probably some situations in which you don't want all your looks-like-a-number data to be returned as a number, but for now it seems to be a good fit for api.joind.in.