I want to do some basic playing in the RESTy resourcey world, in PHP, and this is my first step. A very simple app which shows some RESTy characteristics. The idea is just to figure out how to get it to fit together, not solve any big problems. Prove that I can do the basic stuff. Get all the caching stuff working with ETags, etc.
The app? Why the venerable Guestbook, of course! Who couldn't love a Guestbook? Does anyone even remember Guestbooks? Do people still use Guestbooks? (shiver) Or am I showing my age?
But this is no ordinary Guestbook, this is a RESTy Guestbook. Hence the name. What do I mean by 'RESTy'? If you don't know, then you clearly don't read enough Joe Gregorio.
My real interest in this RESTy stuff is not actually building out the grungy low-level stuff like this. I'm way more interested in things like this:
But before playing with this stuff, I need some substrate on which to play.
Note: the code does not work yet. And is not running anywhere yet. Not even close. The goal would be to make it available, somewhere, once I get it working, and have warm fuzzies that it's fairly secure. It has read/write capabilities, so I need to make sure the 'write' bit is pretty secure.
I'll be building out a PHP script that responds to the HTTP verb / url's in the following ways:
| VERB | URL | ACTION |
|---|---|---|
| GET | [baseURL]/ | return a list of guestbook entries |
| POST | [baseURL]/ | add a new guestbook entry |
| GET | [baseURL]/[entryID] | get a guestbook entry |
| PUT | [baseURL]/[entryID] | update a guestbook entry |
| DELETE | [baseURL]/[entryID] | delete a guestbook entry |
Currently using PHP 5.2.0 on my development box, but will be targetting whatever my hosting provider will let me use (I think currently 5.1.4.
PHPUnit is used for testing. I'm currently using PHPUnit 3.0.3 from PEAR channel pear.symfony-project.com.
Zend Framework is used for it's HttpClient, and for the JSON encoding / decoding functions.
The database being used in sqlite3. To create the database, use:
sqlite3 gRESTbook.sq3 < gRESTbook.sql
It's Pi Day!
I've changed my mind on the data store. Yes, using a database. Using sqlite3, of course, since it's built-in and dirt simple. Though Rick DeNatale just told me today he'd been having problems with sqlite3 getting wedged for his blog (Typo). Sigh. Oh well.
So I've added gRESTbookData.php and gRESTbookDataTests.php; classes to access the data at a high level, and test cases for them, respectively.
Onto the services!
I've been thinking that I should go ahead and create a little curl-ish Flex app to start playing with Flex. I've been using curl to do command-line http testing for now; it would be fun to see how nice of a UI I could put in front of the way I use it.
Added some code to the test cases to actually issue an HTTP request. Just to make sure I could actually do that.
A bunch of code added to the gRESTbook.php file to de-multiplex the request into the actual operation being requested, skeletal bits on how the data will be stored, making sure I can set some HTTP response codes and headers via PHP's header() function.
I'm settling on doing a client for the service in Adobe Flex. And since I just learned that Adobe has a unit testing framework for Flex available called FlexUnit, I think I'll get rid of the PHP unit tests and migrate those to Flex.
Sketching out the initial thoughts on the data store, using the DataStore class. Each guest book entry in a separate file. Two pieces of meta data stored in a separate files as well: the last modified date of the collection, so we don't have to figure out how to 'calculate' this, especially in the case of deletes; and a file to contain the last id used for an entry. I'm thinking the entries will be serially numbered, starting with 1, and the content of the file contains the last id that was created.
Skeletal bits in. gRESTbook.php is totally empty, except for the 'self printing' hack at the top. gRESTbookTests.php has all the structure for the tests, but doesn't actually do anything. At least all the tests pass.
Next step is to add some meat to the test cases, at which point they will all fail. And then add code to gRESTbook to get them to pass.
Created this page, and outlined the idea of what this is from 10K feet, including the usual HTTP VERB / URL / action table.
writeFooter(); ?>