Posts in "PHP" tag

How to debug REST/JSON services

I recently had to write a webservice in PHP that were to be used by iPhone/Android apps to post data and images to. With standard HTTP POSTS I’ve usually just created a quick dummy html to post data to the server to test, but this time I had to do some research on how to quickly test the services while developing… Just writing it down here so I don’t forget :-)

cURL to the rescue

So, let’s say I have a service that requires a session_id, title and comment_text. This can be called from the command line with cURL like this:

curl -X POST -d '{"session_id":"2399024390","title":"This is my title","comment_text":"Some text"}' http://example.com/api/method

You’ll get the response on the command line right there so it makes it quick to debug stuff while developing.

What about posting files?

I had a challenge where one of the services were to accept a base64_encoded image in the JSON post, so the simple curl example above wouldn’t suffice. My friend Frode had the idea of using PHP on the command line to save the JSON request array to a file and then posting that request using cURL afterwards. That did the trick!

So, to create the JSON array to POST to the server I ran this PHP code:

php -r 'file_put_contents("json.txt", json_encode(array("session_id" => "3d6e4871170d4c1c2d91a18264904587b2c8ee0d","image_caption" => "This is an image","sender_email" => "blabla@gmail.com","sender" => "My nick", "image_base64" => base64_encode(file_get_contents("gmail.png")))));'

Notice the “image_base64” key in the JSON array there. The server expects to receive a base64 encoded binary image (this is how I got it from the apps that were interacting with the webservice). So that code would read gmail.png which was located in the same folder, base64 encode it and add it to the JSON array.

With a complete JSON array all that remained was the actual POST:


curl -X POST -d @json.txt http://example.com/gallery/api/image/post

And the server returned {“status”:”ok”} and all was well!

There are probably better ways and some awesome tools for doing this out there so please hit me with those in the comments ;-)

PEAR DataObjects vs. Propel vs. EzPDO vs .. Java!

Using an object perstistence layer can be greatly benefitial for any medium to large size project. Or, any project at all some would say. If you don’t know what I’m talking about, I’ll give you a quick example. Usually, in PHP we would do something ugly-bugly like this to retrieve info about a certain item in the database:

$res = mysql_query(“SELECT * FROM article WHERE ID=5”); if($row == mysql_fetch_assoc($res)) { echo $row[“title”]; // do something here }

Compare it to this:

$article = new Article(5); echo $article->getTitle(); // do something here

Ah, the beauty of OO.

My first experience with this was the PEAR DataObject package. I was amazed – it could generate classes based on the tables found in my database automatically, and I could start using them instantly! Yummy!

Lately I’ve been having a look at Propel. You see, I know the Symfony guys chose Propel, and after listening to a podcast with an interview with one of the project leads there, I’m convinced that the guys behind symfony are smart. Smart people choose the best frameworks, so my logic tells me to look at Propel :)

I haven’t tried it yet – but at first glance it looks better than PEAR DO. Why? Well, Propel will generate 4 classes for each table in your database. Overkill you say? Well, read this from the Symfony Model documentation:

Why keep two versions of the data object model, one in model/om/ and another in model/?
You will probably need to add custom methods and attributes to the model objects (think about the ->getName() method that outputs the FirstName and LastName together). But as your project develops, you will also add tables or columns. Whenever you change the schema.xml, you have to make a new call to symfony propel-build-model to generate the object model classes. The Base architecture allows you to keep using the symfony propel-build-model command even after you added custom code to your classes. Here is how it works: the Base classes kept in the model/om/ directory are the ones generated by Propel. You should never modify them since every new build of the model will completely erase these files. But if you need to add custom methods, use the regular object classes of the model/ directory that actually inherit from the previous ones.

Of course, you could just extend the PEAR DataObjects created but it just … well, it just doesn’t seem to be encouraged. I like when a framework encourage me to do stuff The Right Way(TM).

So, Propel it is, I thought – but that was before a co-worker of mine suggested EzPDO which supposedly had a bit of a different approach. They brand themselves as “A simple solution for PHP Object Relational Mapping and Data Persistence” and they seem to be worth a look.

The final solution I’m looking at for solving this issue is using Java combined with PHP. Using the new Zend Platform it’s possible to use Java objects, in PHP code – is that great or what. A little illustration for you, which I found here.

java in php

That way the db stuff can be handled in EJB’s maybe, everything is transferred via SOAP and I can use objects in PHP like I would with Propel etc. It’s all a bit sketchy, but it’s something I’m looking at.

Comments anyone? I’d love to hear some feedback from people who have actually done this ..

PHP is the Devil!

I’m a big fan of podcasts, and recently I stumbled upon this jewel. It’s not a podcast per se, but eight audio files containing presentations from Carson Workshops entitled ‘The Future Of Web Apps’. I’ve listened to three of them by now, and here’s what I’ve learnt so far:

  • Joshua Schachter, Delicious [mp3]; Don’t write for scalability, you won’t know what breaks before it breaks. People will molest your server.
  • Cal Henderson, Flickr [mp3]; Write an API, use an open system; let users know that they can export their data if they don’t want to use your service anymore (it will get you more users!)
  • David Heinemeier Hansson, 37 signals and one of the developers behind Ruby On Rails [mp3]; Flexibility is overrated, and PHP is the Devil!

Great stuff! :) Can’t wait to listen to the next five. And since I’m going to Manchester this weekend (or, stoke-on-trent to be precise, but that’s almost Manchester isn’t it) there should be some travel time to listen to some of this :)r