If you have a simple website, why go Cloud?

If you have a single-server setup and don’t want/need all the scalability you should at least price out a cloud provider. To me, having FULL backups being a no-brainer (Amazon can take filesystem snapshots in under 3 seconds), and being able launch a new server — in case the current one dies — within 3-15 minutes (my experience) are the biggest benefits. How long would that take with a dedicated hosting provider while your customer(s) are yelling at you on the phone? And restoring a dump, tar, rsync or mysql dump once your new server is up?

There are 2 key tools I use to manage my servers on Amazon.
ElasticFox:
You’ll want the ElasticFox plugin for Firefox to help you see and control stuff on Amazon, as it’s a bit better than the AWS GUI — for most things. Also overlaps in basic functionality with RightScale (below), but is more real-time.
RightScale:
To help with ALL sysadmin stuff, you can get and use for production a free “developer” account with RightScale, which puts together Linux images and has all sorts of startup scripts for common LAMP setups, great wikis, the works. It’s 3/4 of the way between “install Linux yourself” and cPanel-based shared hosting systems. They support Amazon, GoGrid and I think Rackspace too.

Why Amazon?

In my research, Amazon still remains, BY FAR, the most advanced (in features) IaaS cloud provider. Couple it with RightScale and you get pretty much all the automation you need, including logging, alerts, auto-scaling (spin-up or down servers based on load), etc. Amazon keeps on adding features, seemingly on a monthly basis, and they very much listen to what customers want. They recently added “huge” servers with up to 64GB of RAM and 8 CPUs, and the ability to hold your root partition on non-volatile storage (used to be that once you shut down your machine, you lost the contents of root — not a big deal to work around anyways, since my data is on persistent EBS disk volumes).

One of my requirements was to be able to host things in Europe, to address EU privacy legal issues — “EU data must be hosted in the EU” — so Amazon is one of the few (only?) cloud providers that has a datacenter there.
I was also concerned about disaster recovery, and Amazon seems to have more geographically-disperse datacenters than others. Couple that with their S3 storage redundancy and available from anywhere, and you’re covered.

Re-think your architecture in a cloud:

Just from scaling purposes, you need your applications to be able to recover/redirect things appropriately when adding or removing a database or web server from your deployments. The same can be said to address high-availability or disaster recovery. I had to re-think many assumptions about a given server being up, or even at the same IP address, so can’t hard-code these things. There are “always available” services that a cloud provider gives you to store these settings — Amazon has SimpleDB, or their storage service S3, both of which are highly redundant & available.

Scale horizontally (add more servers), not vertically (add more RAM/CPU) is the key mantra in cloud computing. It’s a different mindset to have in architecting your application. You can, and sometimes should, take it to the extreme of making each server do just 1 thing, particularly if you have to process a lot of data. The typical example of this is a website that allows users to upload video, which has to be down-scaled and put into a database or better yet into the cloud storage service (like Amazon S3). So you’d have a queue system (see Amazon SQS for a solution) that has your front-end web server put the raw video in the queue, sends a message to the processing server, which all it ever does is “check queue, process item if found, repeat”.

Yes, there are some quirks to work around in cloud providers, but they’re worth it for me if nothing else for peace of mind. I wish I could have >1 IP address per server on Amazon.

About the Author
As I said, this post is actually a comment contributed by Daniel Kadosh. Daniel works for Affinegy, Inc., a software company in Austin, TX
http://www.affinegy.com

What are your thoughts? If you’ve got an opinion, share it, and I may even give it the same attention I did for Daniel

• This worked for me… it may not work for you. If you never make it to the “make install” step of the PHP build, you won’t screw up your system so you can feel relatively safe trying this. However, I can’t support you if something goes wrong. Don’t worry tho, you shouldn’t run into many issues
• The steps in this tutorial are munged together from various other sources on the web. I’d like to credit these people if possible, but I don’t have a list of all my various sources… if your stuff is on here, lemme know and I’ll make sure you’re properly credited and linked to
• You MUST have the xcode developer tools installed for any of this to work. You’ll know right away if you don’t, as “make” will be an unknown command for you. These are on your Snow Leopard install DVD if you don’t have them…

OK, moving on…

Download Source Files

We’re going to need to grab a few things to get started. So, fire up a terminal, and type in the following:

sudo mkdir /src
sudo chown [your username]:staff /src
cd /src
mkdir pcre
mkdir php
cd pcre
curl ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/pcre-7.7.tar.gz -O
cd ../php
curl http://www.opensource.apple.com/source/apache_mod_php/apache_mod_php-53/php-5.3.0.tar.bz2 -O

What we’ve got is the PHP 5.3 package from Apple, and the PCRE library… everything else we need is already on our system. Let’s get compiling…

Compile PCRE

We need to compile PCRE into a local directory (not system-wide) so the PHP compiler has access to the headers it will need. This is pretty easy, just run the following:

cd /src/pcre
tar -zxvf pcre-7.7.tar.gz
cd pcre-7.7
./configure --disable-shared --enable-static
make && make install DESTDIR=/src/pcre/pcre-local

That’s it! Now we can start playing around with PHP

Compile PHP

Basically, what we’re going to be doing here is recompiling PHP 5.3 with the same config parameters as it was originally built with, but changing the things we need for GD and PCRE. It’s important that you follow all the steps outlined here, or you’ll get some weird compile errors. Also, if you’re a bit uncomfortable about recompiling, remember that you’re not going to mess anything up until you actually run the “make install” command. So, if the compile fails for any reason, your current PHP install isn’t going to get messed up in any way.

So, let’s get started:

cd /src/php
bunzip2 php-5.3.0.tar.bz2 && tar -xvf php-5.3.0.tar
cd php-5.3.0

Now, we’ll need to edit one file to fix a compile error we’ll run into. Open /src/php/php-5.3.0/ext/iconv/iconv.c in your editor of choice, and head to line 186. We need to change the line from:
“#define iconv libiconv”
to
“#define iconv iconv”

Once you’ve done that, we’re good to go. Assuming you’re still in /src/php/php-5.3.0:

MACOSX_DEPLOYMENT_TARGET=10.6
CFLAGS="-arch x86_64 -g -Os -pipe -no-cpp-precomp"
CCFLAGS="-arch x86_64 -g -Os -pipe"
CXXFLAGS="-arch x86_64 -g -Os -pipe"
LDFLAGS="-arch x86_64 -bind_at_load"
export CFLAGS CXXFLAGS LDFLAGS CCFLAGS MACOSX_DEPLOYMENT_TARGET
./configure --prefix=/usr \
--mandir=/usr/share/man \
--infodir=/usr/share/info \
--disable-dependency-tracking \
--sysconfdir=/private/etc \
--with-apxs2=/usr/sbin/apxs \
--enable-cli \
--with-config-file-path=/etc \
--with-libxml-dir=/usr \
--with-openssl=/usr \
--with-kerberos=/usr \
--with-zlib=/usr \
--enable-bcmath \
--with-bz2=/usr \
--enable-calendar \
--with-curl=/usr \
--enable-exif \
--enable-ftp \
--with-gd \
--with-jpeg-dir=/usr/local/lib \
--with-png-dir=/usr/X11R6 \
--with-freetype-dir=/usr/X11R6 \
--with-xpm-dir=/usr/X11R6 \
--with-ldap=/usr \
--with-ldap-sasl=/usr \
--enable-mbstring \
--enable-mbregex \
--with-mysql=mysqlnd \
--with-mysqli=mysqlnd \
--with-pdo-mysql=mysqlnd \
--with-mysql-sock=/tmp/mysql.sock \
--with-iodbc=/usr \
--enable-shmop \
--with-snmp=/usr \
--enable-soap \
--enable-sockets \
--enable-sysvmsg \
--enable-sysvsem \
--enable-sysvshm \
--with-xmlrpc \
--with-iconv-dir=/usr \
--with-xsl=/usr \
--with-pcre-regex=/src/pcre/pcre-local/usr/local

If everything completed without error, you’re ready to compile (again, if this fails, nothing is messed up with your current PHP installation):

export EXTRA_CFLAGS="-lresolv"
make

This will take a few moments, so go grab a coffee or something If this step completed properly (i.e you get some message about “don’t forget to run make test”), you’re ready to finish up. One thing I like to do is back up my current php.ini file, but if you haven’t tweaked it (or created it for that matter), you don’t need to do this:

sudo cp /etc/php.ini /etc/php.ini.bak

Now, you can install our fresh PHP build:

sudo make install

That’s it! Now, you can copy your old php.ini file back, and restart apache:

sudo cp /etc/php.ini.bak /etc/php.ini
sudo apachectl restart

If you set up a phpinfo() somewhere in your doc root, you should now see something like the following in the GD section of it:

Enjoy

Now, all that being said, I’m more than happy to take suggestions from anyone if they’ve got them. If there’s something you’d like to know more about, or you just have a cool idea for an article, drop me a line in the comments. Otherwise, stay tuned for new stuff whenever I think of it Also, you can always follow me on twitter, or subscribe to my RSS feed as I post various interesting links and randomness in both places.

What is Cloud Computing?

So, before we get into the why, let’s go over the what a little bit more (if you’re familiar with services like EC2 or S3, feel free to skip this part). In a nutshell, cloud computing is really nothing more than virtualized private servers on steroids. Traditionally, if you wanted to host a site or app you would either get a shared hosting account somewhere, or get your own dedicated box (or many boxes). This generally works fine, but there are a lot of drawbacks to the so-called traditional way of doing things. We’ll get into this in a little bit, but for the moment we only need to know that these solutions involved actual physical servers. A dedicated server is just that, a dedicated piece of hardware for you to use… shared hosting is similar in the fact that you’re merely a tenant on a dedicated server (you could relate it to renting an apartment vs. owning a home).

Anyway, cloud computing is essentially the same as dedicated hosting, except for one very important distinction: you’re not using a physical server, your server is virtualized. That’s it, it’s really that simple! However, this simplicity has a lot of very important benefits that lead it to beat the hell out of any traditional hosting situation. It also has one very significant draw-back as well. We’ll get into these next…

Why Cloud Computing is Awesome

Before we get into any drawbacks of this “cloud” stuff, let’s go over all the great things about it.

It’s Cheap

Cloud hosting is super-cheap compared to traditional dedicated hosting. A cloud-based server doesn’t take up space in racks, doesn’t required dedicated hardware, or any of the other costly stuff that physical servers require. Instead, one uber-powerful server can host several virtual servers, thus cutting down on costs at the data center, which gets passed to us.

On top of that, a lot of cloud hosting providers only charge you for what you use. If you only need a server for a few days / weeks for testing, you only need to pay for the time it was up and running. No commitments, no monthly charges whether you use the server or not, nothing. Awesome.

It’s Reliable

Early adopters of cloud hosting will tell you horror stories about their cloud servers randomly disappearing and other fun stuff like that, but this is no longer the case with any of the providers. This simply doesn’t happen any more. That aside, the fact that your server is virtualized adds a ton of other reliability benefits. Think about it, you don’t have any physical RAM, CPU, or hard drives to fail. Even better, the aforementioned uber-servers that your cloud server lives on take redundancy to the extreme, so there’s no reasonable worry about the host machine’s hardware failing, thus causing your server to fail. To make matters better, if in the rare event that the host machine fails, guess what? Your virtual server is simply (and quickly) moved to a server that doesn’t have issues. How cool is that?

It get’s better. Unlike shared hosting (which you should never use, which is another article I suppose) where your site shares resources with all the other shared sites on the server, you get dedicated resources. Imagine you’re on a shared host and somebody else’s site gets a huge traffic spike… their site will start to consume a ton of server resources, which get robbed from your site. With cloud hosting, this doesn’t happen. You get a guaranteed share of ram, disk, and CPU… same as you would with a dedicated server.

Finally, backups of cloud servers are super-reliable and super-awesome. With dedicated hosting, you can easily set up automated back-ups on your server, but those never back everything up. You still have to write cron jobs to do database dumps as the automated backup stuff won’t ever touch an active database data file, and you still have to say what it is you want backed up outside of that. With cloud hosting, your WHOLE SERVER is backed up. Remember, it’s virtualized, so a backup is nothing more than a snapshot. Like I said, super-awesome.

It’s Fast to Set Up

SInce everything’s virtual, you can usually get a cloud server up and running in minutes. There’s no hardware to plug into a rack, no servers to purchase, none of that junk. You just (essentially) tell the hosting provider you want a server, and they create it for you. This means that you can create and destroy servers as you need them, without having to make all sorts of plans in advance or waiting around.

It’s SUPER Scalable

One of the biggest draw-backs with dedicated hosting (or shared for that matter) is that you can’t scale easily, or even at all. You get a server with a certain amount of RAM and disk space, and whatever CPU happened to be installed, and you’re stuck. If you want to add more RAM, you usually end up paying through the nose for it… same with disk space. And if you want a newer CPU, you get a new server.

Imagine your app gets a traffic spike and your machine gets overloaded. How fast can you get another server set up to accommodate the load? At best, with dedicated hosting, 24 hours, and then you’ve still got to set everything up and possibly deal with load balancers, etc. Say you go ahead and do that, and the traffic spike drops after a month. What now? You’ve got way more computing power than you need, and you probably can’t get rid of the extra server easily… so you’re stuck with it (more money, more problems).

Well, this doesn’t happen with cloud servers. If you get a traffic spike, you simply scale the server up. More often than not, you simply need more RAM to deal with high load on your server. Guess what? Since your cloud server is virtualized, more RAM is only a matter of having the hosting provider allocate it to your machine. This usually involves a few clicks in a web interface, and a few more minutes for the scaling to happen. Even better, when you no longer need the extra resources, you can just as easily scale down. No headaches, and you don’t need to spend a ton of money to do it (which also goes back to the cheapness of cloud hosting).

Even if more RAM won’t cut it (maybe you need another database server or something like that), spinning up new sites is easy. Hell, you can usually clone your current server (or one of your servers if you have several) from one of your snapshots. So, not only can you get a new server up in minutes, but it’s already got everything ready and running on it. More awesomeness.

The Drawback of Cloud Hosting

Despite all the goodness we just went over, there’s one big problem with cloud hosting / computing. You have to set everything up yourself. There’s no control panel (unless you install one), nothing. When you spin up a server, you get a root password and a clean OS install. If you don’t know what you’re doing, or how to set things up, you’re in for a long and arduous set up process.

But things aren’t as bad as it seems. There are a lot of really well-written tutorials out there, often written by the hosting provider, that will walk you through getting your servers set up however you need them to be. Even better, there are also some really cool services in the works that will take care of this setup for you (one of which I’m working on… stay tuned ). So, this issue is rapidly becoming moot, but it’s still important to mention and acknowledge.

Why All This is Important to PHP Developers

You are probably asking yourself why this matters to you as a PHP developer… and with good reason. More often than not, the traditional ways of doing things have been more than adequate for us. Very often, the “best practice” setup for development has been to set up a local development environment with XAMPP/WAMP/MAMP, and to buy cheap shared or dedicated hosting somewhere for the actual site / app to run in production on.

I, however, think this approach sucks. As easy as stuff like XAMPP is, it’s always got shortcomings. If you want to try and use any technology that isn’t bundled with these packages, you’re pretty screwed (try and set up memcache on windows… lemme know how that goes). There are so many cool new technologies out there that I see many developers ignoring simply because there’s no easy way to work with them from a development perspective. Honestly, are you going to waste a ton of time trying to recompile PHP to include the bundled GD libraries, or some other thing, or installing software like Image Magick, Sphinx, Memcache, APC, whatever? It’s not always easy, so it’s rarely tackled. Perhaps you want to play around with PHP 5.3 or MySQL 6, or Postgres, MySQL replication or something else because you’re curious… how do you do this locally?

If you’re savvy, your answer to me would probably be to set up a local VM with VMware or VirtualBox. Not a bad answer, but those are a pain sometimes too. Local VMs can take valuable resources from your machine, and if you’re using an IDE, you’re probably already short on RAM (especially those of you using eclipse or eclipse-based IDEs). So you’ll turn these VMs on or off when you need them, but that’s also a pain.

Let’s take it one step further… You probably work on lots of different projects. If you’re like me, you run these all against some local Apache installation in subfolders while you’re developing (i.e. localhost/projecta and localhost/projectb). Well, that’s not a real representation of how things are going to run in production, which is never a good thing. You probably also use SVN or Git (if you don’t use SCM for development, start. Trust me, do it), and you probably just host that stuff locally. This is also less than ideal.

I’m sure you see where I’m going with all this. All these problems can be solved with cloud hosting. I don’t feel like I need to go into great detail here, as these solutions should be pretty self-evident. Think about it… if you want to play around with PHP 5.3 or some other new technology, you need only spin up a cloud server for a few days / weeks and do so. It’s cheap, easy, and you won’t run the risk of borking whatever local dev environment you’ve got set up.

But there’s a bit more to it than that. Say you want to test a migration from one version of something to another, or an upgrade process for an app you’ve written. If you’ve got an environment set up in a cloud, you need only take a snapshot of your server’s current state and then attempt the migration / upgrade / whatever. If something gets screwed up, revert to the snapshot and try again… that easy. You can’t argue that this isn’t a much better alternative to trying to do this with a dedicated server or local dev environment.

Finally, it’s simply a better way to develop. I’ve got a local XAMPP install that I use, admittedly, but I’ve also got several servers in the cloud. All my wiki, source control, and other important dev-related stuff lives on a dev server I’ve got set up in the cloud. It’s backed up, it works, and I’ve got total control over how it’s set up. I’ve also got a few other dev / production servers set up (this site is running on one) for my various rails / php projects that I work on. I can easily play around with new stuff without worrying about screwing anything up, I can keep all my development and testing properly isolated (I know people who run their dev and production environments on the same dedicated server… that’s playing with fire my friends), and everything just works.

Getting Started

So, how do you get started with the cloud. Well, that all depends on you… if you’re comfortable with the command line and general setup / config / admin of *nix servers, you should just dive into it. If you’re not (and there’s nothing wrong with that), you can either decide to learn, or sit tight for a bit. Like I said, there are people (including myself) that are working on taking the configuration and setup management of cloud servers and making it nothing more than a few clicks on a control panel.

Either way, you really do need to get into the cloud as soon as you can. Everything’s going to be moving in this direction (and already is in a lot of cases), and it’s also simply a better way to do things all around. I haven’t even touched on the beauty of cloud hosting for production environments, which is another discussion altogether.

Anyway, I leave you with a few links to the most popular cloud hosting providers. Feel free to shoot any questions / comments you may have my way in the comments!

• Amazon EC2 – EC2 was the first major cloud computing offering, and it’s the most robust as far as service options (stuff like virtual load balancers, etc.). They’re also a bit pricier than other providers, but they’re damn good
• Slicehost – Slicehost is just awesome… and cheap. A server will cost you around $20 / month. They’ve also got amazing articles to help you get pretty much anything you’d like set up on your server. Highly recommend them
• Rackspace Cloud – Also an awesome service. They are a bit cheaper than slicehost (around $12 / month to start), but are priced a bit more variably (slicehost is more of a set fee)… you pay per hour for the server plus bandwidth. Rackspace owns the rackspace cloud (obviously) and Slicehost, so it’s really a matter of preference here. I actually like the Rackspace Cloud a bit more merely for the pricing scheme since I spin servers up and down more frequently to play around with stuff
]]> http://www.gen-x-design.com/archives/the-importance-of-cloud-computing-for-php-developers/feed/ 4 http://www.gen-x-design.com/archives/php-thumb-30-released/ http://www.gen-x-design.com/archives/php-thumb-30-released/#comments Wed, 10 Jun 2009 19:23:21 +0000 Ian http://www.gen-x-design.com/?p=309

Well, it’s been a long time coming, but I’ve finally managed to get the next release of my PHP Thumbnailer library completed! I’m also happy to announce that the project finally has its own website: http://phpthumb.gxdlabs.com. I’ve put a lot of work into bringing the class up to date, making it extensible, and most of all, making sure its well documented! I’ve also tried to make it easier to get help through either bug reports or forums dedicated to the project itself.

Rather than go into any detail, I want to encourage you to check out the project’s new site. Feel free, however, to share any thoughts you have in the comments for this post

]]> http://www.gen-x-design.com/archives/php-thumb-30-released/feed/ 7 http://www.gen-x-design.com/archives/web-developer-collection-packaged-up-firefox-extensions/ http://www.gen-x-design.com/archives/web-developer-collection-packaged-up-firefox-extensions/#comments Wed, 10 Jun 2009 18:14:34 +0000 Ian http://www.gen-x-design.com/?p=304

Mozilla announced a new feature for add-ons today: collections. It also looks like they’re getting the ball rolling with several useful collections, such as the Web Developer Collection. It includes all sorts of goodness like Firebug, ySlow, GreaseMonkey, ColorZilla, and many more. Well worth a quick visit.
FireFox Web Developer Collection

]]> http://www.gen-x-design.com/archives/web-developer-collection-packaged-up-firefox-extensions/feed/ 0 http://www.gen-x-design.com/archives/mootools-scrollspy-surprising-useful-js-plugin/ http://www.gen-x-design.com/archives/mootools-scrollspy-surprising-useful-js-plugin/#comments Fri, 29 May 2009 21:20:51 +0000 Ian http://www.gen-x-design.com/?p=299

David Walsh has put together a really handy plugin for MooTools called ScrollSpy. What impressed me the most was the automatic display of a “Return to Top” link on your page once you’ve scrolled beyond a certain boundary. There are also a handful of other neat demos worth checking out. Sounds simple, but if you think about it, there are tons of great applications for this plugin.
http://davidwalsh.name/scrollspy

]]> http://www.gen-x-design.com/archives/mootools-scrollspy-surprising-useful-js-plugin/feed/ 0 http://www.gen-x-design.com/archives/jquery-vs-mootools/ http://www.gen-x-design.com/archives/jquery-vs-mootools/#comments Thu, 21 May 2009 18:00:03 +0000 Ian http://www.gen-x-design.com/?p=292

It’s been said a thousand times I’m sure, but picking the right JavaScript framework is a pain. There are all sorts of biased arguments for one vs. another, but there’s really nothing subjective out there… until now. Arguably, jQuery is probably the most popular JS framework out in the wild, but that doesn’t always mean it’s the best choice. What you choose should really depend on what you’re trying to do. Aaron Newton of Clientcide has put together a really impressive look at jQuery vs. MooTools, which doesn’t categorically say one is better than the other, but, rather, goes into detail about why one framework is better than the other based on your needs. Definitely worth a read:
www.jqueryvsmootools.com

]]> http://www.gen-x-design.com/archives/jquery-vs-mootools/feed/ 1 http://www.gen-x-design.com/archives/doctrine-php-object-relational-mapper/ http://www.gen-x-design.com/archives/doctrine-php-object-relational-mapper/#comments Wed, 20 May 2009 20:59:28 +0000 Ian http://www.gen-x-design.com/?p=288

ORM is certainly a very popular concept these days, but I haven’t really come across any PHP implementations that I found worth-while. Sure, big frameworks like CakePHP may have ORM functionality, but I’m not a fan of huge frameworks. I’ve also dabbled in my own implementations, but never got too far, as I’m not a fan of re-inventing the wheel. At any rate, I stumbled across Doctrine by accident (good ol’ RSS readers), and am impressed, mostly because it’s something that can be integrated into existing projects / frameworks.
www.doctrine-project.org

]]> http://www.gen-x-design.com/archives/doctrine-php-object-relational-mapper/feed/ 2 http://www.gen-x-design.com/archives/making-restful-requests-in-php/ http://www.gen-x-design.com/archives/making-restful-requests-in-php/#comments Thu, 14 May 2009 19:47:03 +0000 Ian http://www.gen-x-design.com/?p=269 APIs have become a very commonplace part of many popular web sites and services… especially REST APIs. I’ve already discussed how you can roll your own REST API for your PHP apps, but I’ve also received countless requests to go over how to actually make RESTful requests. That’s exactly what we’ll take a look at in this article. Before we dive in, however, I want to make sure you’ve got a basic understanding of how REST APIs work, so if you’re a bit shaky or unfamiliar with the concept, head on over to my previous article on REST and read up (you don’t need to go over the implementation stuff if you don’t want, just read the first part of the article). Seriously, do it… this article is written with the assumption you’re familiar with the concepts of REST.

Anyway, without any further delay, let’s take a look at what we’re going to cover…


The Basics of a RESTful Request

Every REST request consists of essentially the same basic parts:

• The URL – This is the URL we’ll be making a request against (often referred to as a resource).
• The Verb – GET, POST, PUT, or DELETE… there are some others out there, but these are the 4 most common ones.
• The Params – The parameters we’ll be supplying to the API, often referred to as the request body.
• Credentials – Username and password… we’ll cover HTTP Digest auth credentials.

And, of course, we’ll have a few pieces for our response as well:

• The Response Body – The actual response body the API gave us.
• The Response Status Code – The HTTP status code the API responded with.
• Other Response Info – We’ll also have some other interesting info in the response.

Nothing really unexpected here, everything’s probably looking like what you’d expect: a request and a response.

So, on to the answer to the most important question: “How the heck do you actually make the request?!?!?”

REST & PHP – Curl to the Rescue

You may have already guessed we’d be using curl (or suspected it perhaps)… and if you didn’t, well, that’s what we’ll be using Anyway, if you’ve ever worked with Curl in PHP, you’re probably aware that making GET and POST requests are pretty straight-forward, but the PUT and DELETE requests are a little less obvious. Luckily, they’re pretty easy once you know how to do them, the problem is that they’re very poorly documented. We’ll go over them soon, but let’s get started with a little code. We’re going to be building a class that we can use to make requests and deal with their responses, so why don’t we build up a bit of a base class, and then start filling things in:

class RestRequest
{
	protected $url;
	protected $verb;
	protected $requestBody;
	protected $requestLength;
	protected $username;
	protected $password;
	protected $acceptType;
	protected $responseBody;
	protected $responseInfo;

	public function __construct ($url = null, $verb = 'GET', $requestBody = null)
	{
		$this->url				= $url;
		$this->verb				= $verb;
		$this->requestBody		= $requestBody;
		$this->requestLength		= 0;
		$this->username			= null;
		$this->password			= null;
		$this->acceptType		= 'application/json';
		$this->responseBody		= null;
		$this->responseInfo		= null;

		if ($this->requestBody !== null)
		{
			$this->buildPostBody();
		}
	}

	public function flush ()
	{
		$this->requestBody		= null;
		$this->requestLength		= 0;
		$this->verb				= 'GET';
		$this->responseBody		= null;
		$this->responseInfo		= null;
	}

	public function execute ()
	{

	}

	public function buildPostBody ($data = null)
	{

	}

	protected function executeGet ($ch)
	{		

	}

	protected function executePost ($ch)
	{

	}

	protected function executePut ($ch)
	{

	}

	protected function executeDelete ($ch)
	{

	}

	protected function doExecute (&$curlHandle)
	{

	}

	protected function setCurlOpts (&$curlHandle)
	{

	}

	protected function setAuth (&$curlHandle)
	{

	}
}

So, what we’ve got here is essentially all of the functions we’ll need to make this whole thing work right. We’ll cover each of the function individually, but let’s take a look at the class members:

• $url – The URL we’ll be requesting against
• $verb – The type of request we’ll be making (what verb to use)
• $requestBody – The request body we’ll send with PUT and POST requests
• $requestLength – An internally used variable for PUT requests (more on this later)
• $username – The username to use for this request
• $password – I’ll let you guess
• $acceptType – What kind of content we’ll accept as a response (not all APIs use this to determine the response format, but we’ll be robust)
• $responseBody – The body of our response
• $responseInfo – All the other goodness from our response (status code, etc.)

Not too rough, right? And if you take a look at the constructor, you’ll see things are pretty straight-forward as well. We’ve also got a flush function. This allows us to use the same object to make multiple requests by only clearing out certain member variables (notice username / password aren’t touched). You may have also noticed we’re missing getters / setters… this is simply to keep the code a little shorter. The final class will have them.

Making Requests – The Prep Work

Let’s go ahead and fill in some of the functions that do prep work for us, and then we’ll dig into making the requests. Anyway, let’s take a look at these “init” functions..

buildPostBody
This function will take an array and prepare it for being posted (or put as well):

	public function buildPostBody ($data = null)
	{
		$data = ($data !== null) ? $data : $this->requestBody;

		if (!is_array($data))
		{
			throw new InvalidArgumentException('Invalid data input for postBody.  Array expected');
		}

		$data = http_build_query($data, '', '&');
		$this->requestBody = $data;
	}

Notice how we will throw exceptions if we receive anything other than an array? This is important, as we don’t want our data to be malformed (or an error to be thrown by http_build_query). Also, you may be thinking that I’m using an exception type that isn’t defined anywhere… well, it is (if you’re using PHP 5). I won’t go off on a tangent, but check out the PHP SPL for more info. All you need to know is that the InvalidArgumentException is already defined for you

setCurlOpts
This function will take care of all the curl options common to all our requests:

	protected function setCurlOpts (&$curlHandle)
	{
		curl_setopt($curlHandle, CURLOPT_TIMEOUT, 10);
		curl_setopt($curlHandle, CURLOPT_URL, $this->url);
		curl_setopt($curlHandle, CURLOPT_RETURNTRANSFER, true);
		curl_setopt($curlHandle, CURLOPT_HTTPHEADER, array ('Accept: ' . $this->acceptType));
	}

setAuth
If we’ve got a username and password set on the class, we’ll set up the auth options on the curl request with this function:

	protected function setAuth (&$curlHandle)
	{
		if ($this->username !== null && $this->password !== null)
		{
			curl_setopt($curlHandle, CURLOPT_HTTPAUTH, CURLAUTH_DIGEST);
			curl_setopt($curlHandle, CURLOPT_USERPWD, $this->username . ':' . $this->password);
		}
	}

I mentioned earlier that we’re only going to cover HTTP Digest authentication in this class, but you could adapt this function to suit your needs however you wanted depending on what the API(s) you’re consuming require.

Making the REST Requests

We’re about ready to cover how to make the individual verb requests, but we need to do just a little bit more work filling in the common functionality. We’ll go ahead and create our doExecute and execute functions now:

	public function execute ()
	{
		$ch = curl_init();
		$this->setAuth($ch);

		try
		{
			switch (strtoupper($this->verb))
			{
				case 'GET':
					$this->executeGet($ch);
					break;
				case 'POST':
					$this->executePost($ch);
					break;
				case 'PUT':
					$this->executePut($ch);
					break;
				case 'DELETE':
					$this->executeDelete($ch);
					break;
				default:
					throw new InvalidArgumentException('Current verb (' . $this->verb . ') is an invalid REST verb.');
			}
		}
		catch (InvalidArgumentException $e)
		{
			curl_close($ch);
			throw $e;
		}
		catch (Exception $e)
		{
			curl_close($ch);
			throw $e;
		}

	}

	protected function doExecute (&$curlHandle)
	{
		$this->setCurlOpts($curlHandle);
		$this->responseBody = curl_exec($curlHandle);
		$this->responseInfo	= curl_getinfo($curlHandle);

		curl_close($curlHandle);
	}

Looks like a lot of code, but it’s actually pretty simple stuff.

First, looking at execute, you’ll see that we set up a curl handle variable ($ch), and then run the setAuth function. Since we pass $ch around by reference, the functions will directly manipulate the variable without any need to return it. Now, I could make the $ch a member variable, but for the sake of this example, I wanted to show how everything gets passed around a little more explicitly. Anyway, the next thing we do is normalize the verb, and run through our switch statement to determine what function will get executed. If we don’t find a matching case, we throw an exception. We also wrap the whole thing in a try / catch block so we can properly catch exceptions, close our curl handle, then throw the exception again (presumably for some other error handler or try / catch block elsewhere in the code).

Moving on to the doExecute function, you’ll see all we really do here is set all the common curl options with setCurlOpts, execute the request, and get the response body and info. We’ll take a look at those in a bit, but let’s get to the individual request functions.

GET Requests

These requests are about as easy as they get. Since your params will be a part of the URL, there isn’t much to do outside of actually making the request. So our code is nice and easy:

	protected function executeGet ($ch)
	{
		$this->doExecute($ch);
	}

‘Nuff said

POST Requests

These too are pretty easy to accomplish, and POSTing with Curl is well-documented. Nonetheless, here’s what our function looks like:

	protected function executePost ($ch)
	{
		if (!is_string($this->requestBody))
		{
			$this->buildPostBody();
		}

		curl_setopt($ch, CURLOPT_POSTFIELDS, $this->requestBody);
		curl_setopt($ch, CURLOPT_POST, 1);

		$this->doExecute($ch);
	}

All we really do here is make sure the request body is a string, and if it isn’t that means we need to prepare it… so we do. Then we tell Curl to make a POST request with the provided POST body. That’s all there is to it! Moving on…

PUT Requests in PHP

Ah, PUT requests… These are the big mystery. Admittedly, there are a few articles out there covering how to do them, but they’re not super-easy to come across. I did, however, manage to find a few and here’s what I came up with:

	protected function executePut ($ch)
	{
		if (!is_string($this->requestBody))
		{
			$this->buildPostBody();
		}

		$this->requestLength = strlen($this->requestBody);

		$fh = fopen('php://memory', 'rw');
		fwrite($fh, $this->requestBody);
		rewind($fh);

		curl_setopt($ch, CURLOPT_INFILE, $fh);
		curl_setopt($ch, CURLOPT_INFILESIZE, $this->requestLength);
		curl_setopt($ch, CURLOPT_PUT, true);

		$this->doExecute($ch);

		fclose($fh);
	}

A little funky, right? Well, this boils down to the way PUT requests are technically supposed to work. RESTful APIs don’t quite use a PUT the way they were originally intended, which is for file uploads. As such, we need to stream the data to the web server. So we open an internal php memory resource, write our request body to it, and then pass the handle for that memory resource to curl. We also calculate the size of it (in bytes), so that our full body will be received on the API side of things. I suppose that doesn’t necessarily need to make any sense to you, as long as you trust that it works

DELETE Requests in PHP

Deletes, when done as they’re intended (no post body), are easy. Remember, you’re not really supposed to send any body for a delete request, as you’re merely sending a command to a resource (i.e. /api/user/1). Here’s the code:

	protected function executeDelete ($ch)
	{
		curl_setopt($ch, CURLOPT_CUSTOMREQUEST, 'DELETE');

		$this->doExecute($ch);
	}

Now, if you need to send a body for some reason, you can do it by adding the same stuff you use for a PUT request, but swap out the CURLOPT_PUT line for the existing CURLOPT_CUSTOMREQUEST line that we’ve got in this function. I don’t advocate this, but it works like a champ if you need it.

The Response

Now that we’ve got a fully functioning REST requester, let’s take a look at a response. So, making a request against an imaginary API looks something like:

$request = new RestRequest('http://example.com/api/user/1', 'GET');
$request->execute();

echo '<pre>' . print_r($request, true) . '</pre>';

Which gives us output similar to:

RestRequest Object
(
    [url:protected] => http://example.com/api/user/1
    [verb:protected] => GET
    [requestBody:protected] =>
    [requestLength:protected] => 0
    [username:protected] =>
    [password:protected] =>
    [acceptType:protected] => application/json
    [responseBody:protected] => [RESPONSE BODY HERE]
    [responseInfo:protected] => Array
        (
            [url] => http://example.com/api/user/1
            [content_type] => application/json
            [http_code] => 200
            [header_size] => 232
            [request_size] => 192
            [filetime] => -1
            [ssl_verify_result] => 0
            [redirect_count] => 0
            [total_time] => 0.015693
            [namelookup_time] => 0.0004
            [connect_time] => 0.000571
            [pretransfer_time] => 0.000619
            [size_upload] => 0
            [size_download] => 4276
            [speed_download] => 272478
            [speed_upload] => 0
            [download_content_length] => 4276
            [upload_content_length] => 0
            [starttransfer_time] => 0.015655
            [redirect_time] => 0
        )
)

Take a look at the responseInfo… we’ve got our status code, and all sorts of other good stuff. And, believe it or not, we’re done!

Wrapping Up

Of course, as with all my samples, there’s a lot left for you to do. You’ll probably want to do some processing of the response body and info (such as extracting the status code), or make a few things more robust, but this is all you should need to get started. Hopefully, after this article and the previous one, you’ve got a good idea of how REST APIs work from the server-side, to the client-side, and you’re ready to jump on the REST bandwagon. If you’re not yet convinced… go play with some SOAP APIs, that ought to change your mind

Finally, you can grab the final copy of the class, complete with getters / setters at the link below:
RestRequest.inc.php – Final Source Code

]]> http://www.gen-x-design.com/archives/making-restful-requests-in-php/feed/ 28