Thousands of years ago when we first started building web pages, things were very simple. You'd put some text on the page, maybe even an image, and that was pretty much it. But today it's a whole different ball game. Instead of static pages there's the dynamic applications we've come to depend on. And so, how these applications are designed to communicate becomes very important. In this series I'll introduce you to the REST architecture style. In this article I'll help you to understand exactly what it is, and later I'll show you how it can be implemented in a PHP environment.

He defines the term "REST" for those not familiar and how a typical RESTful API allows other end users/software to interact directly with its data. He outlines some of the common principles of REST and finishes the post with a comparison of two HTTP verbs - PUT and POST.

Often referenced by a few other fancy names, the substitute is generically called a virtual proxy, a sort of stand-in that exploits the neatness of Polymorphism and interacts with the actual domain objects. Proxies aren't new to PHP. Doctrine and Zend Framework 2.x make use of them, although with different aims. On behalf of a didactic cause, however, it would be pretty instructive to implement some custom proxy classes and use them for lazy-loading a few basic aggregates from the database, this way illustrating how virtual proxies do their stuff under the hood.

He starts off by setting up a domain model for a "Post" and "Author" - a typical blog example.Based on the definition of these classes, he creates a mapper class to generate Author objects and an "AuthorProxy" class that uses a "loadAuthor" method to only load in the author's details when a property is requested. He gives a bit more code showing it in action and the difference between using the normal Author and AuthorProxy class.

First off, creating a rich Domain Model, where multiple domain objects with well-defined constraints and rules interact, can be a daunting task. Second, not only is it necessary to define from top to bottom the model itself, but it's also necessary to implement from scratch or reuse a mapping layer in order to move data back and forward between the persistence layer and the model in question.

They include an example of a set of domain models tat relate to one another - a blog setup with posts, comments and users. They show how to create the AbstractEntity to handle a bit of the magic behind the scenes, an example "Post" and "Comment" models and how they can be put to work creating some posts and appending comments. A little bit of markup is included to output the results.

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.

She shows how to grab the controller name from the incoming request (based on her previous code), create the object for it and execute the requested action name. Also included is a sample autoloader and a basic controller - a UsersController with "getAction" and "postAction" methods for responding to GET and POST requests.

We can't send post fields, because we want to send JSON, not pretend to be a form (the merits of an API which accepts POST requests with data in form-format is an interesting debate). Instead, we create the correct JSON data, set that as the body of the POST request, and also set the headers correctly so that the server that receives this request will understand what we sent.

She includes a code example (about ten lines) showing the POSTing process that sets up options using curl's curl_setopt. Be sure to set up the headers to send as "application/json" - that's the trick to letting the remote end know the format.

Although a relatively new entrant in the PHP framework sweepstakes, I've been lately quite intrigued by Slim, a slick RESTful microframework modeled after Ruby's Sinatra, which is coincidentally by far my favorite microframework available for any programming language. In this article I'll show you just how easy it is to get started building a powerful RESTful API using this streamlined framework.

Setup of the framework is as simple as downloading the latest copy from its github repository. It can then be included and used to make the simple routes in his examples. He uses a "games" request type to show how to handle GET, POST and PUT requests through Slim's simple interface.

Since I'm using WordPress.com Stats, I would like to use the rankings generated by this service or plugin. Searching Google, I found some widget called "WordPress.com Stats: Top Posts Widget" which works out of the box (if like to use a widget). In my case I have a custom sidebar with different custom sections using custom code. The following example explains how-to use that code on your website.

WordPress, by default, doesn't track any statistic information about the posts on your site, so you'll need something like the WordPress Stats plugin to get that part working. Once that's there, you can use his code to pull out the posts from the last few days (configurable) and show the most popular of the list.

I had done a refactoring of the way a model was pulling in stats for running backs and receivers for a fantasy game. As a result, in production (you suck Chris) you could not see results for those players. The data was there, I had not properly tested things. A familiar situation. So, I fixed the code and wrote my more-specific-than-before unit tests, but I decided I also wanted to make sure that the output on the page itself worked correctly. This began the descent into madness.

He found several examples of ways to test POST requests but none of them worked in his situation. They used an object chaining method that just didn't cooperate for him, so he figured out another way. The code for it's included in the post - it uses the getRequest method to set up and send the POST request.

A little quirk of PHP $_POST var I encountered while fixing a Salesforce web-to-Lead bug. A Wordpress site was using a form to submit user requests to the Salesforce web-service. The form that submitted the data had the following fields along with the others. The problem was with the multi-select field, only the last value selected in the multi-select was getting captured.

He investigated and found that his code was echoing out all of the values, but wasn't using the "field_name[]" notation with the square brackets to send back multiple values to PHP. Changing this and trying again, he noticed it still wasn't working as expected (with Salesforce). He figured out they're using "raw" versus "cooked" handling of the POSTed variables. Check out the rest of his post to find out what that means.

I've been doing a lot of work with services and working with them in various ways from PHP. There are a few different ways to do this, PHP has a curl extension which is useful, and if you can add PECL extensions then pecl_http is a better bet but there are a couple of different ways of using it. This post shows all these side-by-side.

Code snippets are included for each showing a request to the Flickr API. Be sure to check out the post's comments for more great ideas (like streams, the PEAR HTTP_Client package, Zend_Http_Client and other request types without cURL).