The initial intended use of the Web was to share information among the members of academic research teams. The academicians wanted an easy way to set up and maintain infrastructure to share their findings. They often wanted to link their documents to that of others and previous related work, so they used hyperlinks to site relevant documents.

A useful abstraction of this principle is a document-based hypermedia model that provides content to the users. In the 1990s, Web was used as a platform for distributing information, and it experienced an explosion of users due to the visual appeal of the hypermedia model.

In sync with the ever-increasing number of users, the number of web-based applications too kept up with the pace. With the large number of applications, the volume of data available on the Web has grown tremendously.

With the data available, apart from web applications that could be accessed by users with a web browser, developers built services that could be used by other applications. The programmable Web is the set of enabling technologies that helps developers build services for the Web.

As an example, think of a weather service. More often than not, people who are travelling are interested in weather. So, a travel-related web application could benefit by presenting the users with weather data on the travel website itself. A developer implementing the travel application could consume a weather service to access the weather information and integrate it with the travel application.

RSS (Really Simple Syndication) is a family of Web feed formats used to publish frequently updated contents such as weather information. An RSS document is essentially an XML document. The Yahoo weather service, located at http://developer.yahoo.com/weather/ provides you with an RSS feed of weather. The following code shows how you can access this code using a few lines of PHP:

<?php
$url = 'http://weather.yahooapis.com/forecastrss?p=USNY0996';
$xml = file_get_contents($url);
echo $xml;
?>

This piece of code would fetch the RSS feed that contains the New York weather information. In the above example, the returned XML is just echoed. With a bit of XML processing, you can extract the weather information from the RSS feed returned.

Following is a sample response returned from the service.

<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<rss version="2.0" xmlns:yweather="http://xml.weather.yahoo.com/ns/rss/1.0" xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#">
<channel>
<title>Yahoo! Weather - New York, NY</title>
<link>http://us.rd.yahoo.com/dailynews/rss/weather/New_York__NY/*http://weather.yahoo.com/forecast/USNY0996_f.html</link>
<description>Yahoo! Weather for New York, NY</description>
<language>en-us</language>
<lastBuildDate>Sat, 16 Aug 2008 8:51 am EDT</lastBuildDate>
<ttl>60</ttl>
<yweather:location city="New York" region="NY" country="US"/>
<yweather:units temperature="F" distance="mi" pressure="in" speed="mph"/>
<yweather:wind chill="66" direction="0" speed="3" />
<yweather:atmosphere humidity="87" visibility="7" pressure="30.02" rising="1" />
<yweather:astronomy sunrise="6:08 am" sunset="7:52 pm"/>
<image>
<title>Yahoo! Weather</title>
<width>142</width>
<height>18</height>
<link>http://weather.yahoo.com</link>
<url>http://l.yimg.com/us.yimg.com/i/us/nws/th/main_142b.gif</url>
</image>
<item>
<title>Conditions for New York, NY at 8:51 am EDT</title>
<geo:lat>40.67</geo:lat>
<geo:long>-73.94</geo:long>
<link>http://us.rd.yahoo.com/dailynews/rss/weather/New_York__NY/*http://weather.yahoo.com/forecast/USNY0996_f.html</link>
<pubDate>Sat, 16 Aug 2008 8:51 am EDT</pubDate>
<yweather:condition text="Fair" code="34" temp="66" date="Sat, 16 Aug 2008 8:51 am EDT" />
<description><![CDATA[
<img src="http://l.yimg.com/us.yimg.com/i/us/we/52/34.gif"/><br />
<b>Current Conditions:</b><br />
Fair, 66 F<BR />
<BR /><b>Forecast:</b><BR />
Sat - Mostly Sunny. High: 82 Low: 64<br />
Sun - Sunny. High: 88 Low: 67<br />
<br />
<a href="http://us.rd.yahoo.com/dailynews/rss/weather/New_York__NY/*http://weather.yahoo.com/forecast/USNY0996_f.html">Full Forecast at Yahoo! Weather</a><BR/>
(provided by The Weather Channel)<br/>
]]></description>
<yweather:forecast day="Sat" date="16 Aug 2008" low="64" high="82" text="Mostly Sunny" code="34" />
<yweather:forecast day="Sun" date="17 Aug 2008" low="67" high="88" text="Sunny" code="32" />
<guid isPermaLink="false">USNY0996_2008_08_16_8_51_EDT</guid>
</item>
</channel>
</rss>

Here is how you can process the response to print out the temperature:

$xml = simplexml_load_string($xml);
$node = $xml->channel->item;
$children = $node->children('http://xml.weather.yahoo.com/ns/ rss/1.0'),
$condition = $children->condition;
$attributes = $condition->attributes();
echo $attributes['date'] . " temperature " . $attributes['temp'] ."F";

Technologies such as AJAX (Asynchronous JavaScript and XML) help to use web services effectively in web applications. AJAX makes Web applications to become more interactive, faster, and more user-friendly. Since AJAX runs within the web browser itself, and there is information pulled to the web browser, while the user is looking at the currently available content, it helps to yield better user experience. Before AJAX became popular, web browsing was stateless, meaning that the user would have to wait till the next page is loaded and establish a relationship among the contents between the consecutive pages. But with AJAX, users can have a state-full experience, meaning that the next related content would be pulled down to the web browser asynchronously and the effort required to correlate the related content would be minimal. While the user is viewing a web page, an HTTP request could be sent to a server and data could be retrieved in an XML format and a part of the page is updated. As an example, the weather information could be updated in real time without refreshing the whole page, so the user experience is maximized and the web application becomes more appealing to the users.

Programmable Web uses HTTP as the transportation medium and, most of the time, XML as the message format. In other words, programmable Web could be considered as XML over HTTP. XML is not the only data format available in the programmable Web today. There are a large number of formats available, including HTML, XML, JSON, RSS, Atom, CSV and many other custom formats. Among Web developers, Plain-Old-XML (POX) and JavaScript Object Notation (JSON) are often popular. Though XML is the most popular message format, JSON also enjoys wide acceptance because it is a lightweight data-interchange format. Human Web is HTML over HTTP and the HTML documents are retrieved from web servers rendered by the web browsers and presented to humans in a visually appealing form. When you browse the Web, you access resources using a URI (Uniform Resource Indicator) typed into the address bar of the web browser. The browser uses HTTP GET request and fetches the resources, and the web server will respond with a message filled with the content of the requested resource. Browsers can access a variety of resources using the URIs that include images, videos, and more. Web browsers also use HTTP POST requests to post data filled in by users using forms into web servers. Web servers would process those data and respond accordingly. The HTTP requests can point to URIs that are capable of mapping the request to XML documents representing some forms of data, and those XML documents are processed and the data is consumed by programs.

HTTP is a transport protocol. The HTTP protocol has provisions to represent success or failure status information as well as how the data would be contained in request and response. HTTP by design is a stateless protocol because each request is executed independently, without any knowledge of the requests that came before it.

XML is the data encoding mechanism used in the messages sent. The application-specific data, or in other words, data that relates to business logic would be contained in the XML message.

Let's have a look at an example. Flickr exposes an Application Programming Interface (API) that can be used to manage photos http://www.flickr.com/services/api/. There is a test echo API. Please note that you need an API key to use this API and the API documentation given in the aforementioned URL contains details on how to get one. Following is the sample PHP code to access the echo method:

<?php
$base_url = 'http://api.flickr.com/services/rest/';
$query_string = '';
$params = array (
'method' => 'flickr.test.echo',
'name' => 'Sami',
'api_key' => 'YOUR_API_KEY'
);
foreach ($params as $key => $value) {
$query_string .= "$key=" . urlencode($value) . "&";
}
$url = $base_url . "?" . $query_string;
$client = curl_init($url);
curl_setopt($client, CURLOPT_RETURNTRANSFER, 1);
$xml = curl_exec($client);
curl_close($client);
echo $xml;
HTTPexample?>

Let's look at the HTTP request and response exchanged between the server and the client to understand the format of the messages exchanged.

Request:

GET /services/rest/?method=flickr.test.echo&name=Sami&api_key=YOUR_API_KEY& HTTP/1.1
Host: api.flickr.com

The above request is a GET Request. GET command is immediately followed by the resource location. The resource location that we are accessing is /services/rest/. What follows the location are the parameters. We have three parameters encoded in the request. The method, name, and API key ? character indicates the start of parameters, and parameters are separated from each other using the& character. The final element in the first line of the request is the version of the protocol we are using, in this example HTTP 1.1. The next request header is Host. The resource that we mentioned in the first line is residing on the host api.flickr.com.

Response:

HTTP/1.1 200 OK
Date: Mon, 03 Mar 2008 02:44:19 GMT
P3P: policyref="http://p3p.yahoo.com/w3c/p3p.xml", CP="CAO DSP COR CUR ADM DEV TAI PSA PSD IVAi IVDi CONi TELo OTPi OUR DELi SAMi OTRi UNRi PUBi IND PHY ONL UNI PUR FIN COM NAV INT DEM CNT STA POL HEA PRE GOV"
Set-Cookie: cookie_l10n=en-us%3Bus; expires=Thursday, 03-Mar-11 02:44:19 GMT; path=/; domain=flickr.com
Set-Cookie: cookie_intl=deleted; expires=Sunday, 04-Mar-07 02:44:18 GMT; path=/; domain=flickr.com
Content-Length: 167
Cache-Control: private
Vary: Accept-Encoding
Connection: close
Content-Type: text/xml; charset=utf-8
<?xml version="1.0" encoding="utf-8" ?>
<rsp stat="ok">
<method>flickr.test.echo</method>
<name>Sami</name>
<api_key>YOUR_API_KEY</api_key>
</rsp>

The first line of the response mentions the HTTP protocol version in use, followed by the status code, indicating the status of the response. In this example, we got a 200 OK, which means that the request we sent resulted in a successful response. Followed by the first line, we can see several lines containing various HTTP headers. The HTTP headers and the response body are separated by an empty line. As you can see, the response body contains an XML document.

In the above example, we accessed a resource via a URI, http://api.flickr.com/services/rest/, and we got back an XML document in response. We just witnessed a web service over HTTP in action. Accessing resources via URIs is one of the key principles behind the REST web services. In fact, in the above example, we used Flickr's REST API.

REST is a software architecture style that can be followed while designing software systems. REST is an ideal design style to be followed for web services based software applications. The principles related to REST were first described by Roy Fielding in his Ph.D. dissertation. You can find the chapter that describes REST in that dissertation here: www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm. Following are the key REST principles in brief:

Often, REST architectural style is referred to as the architectural style of the Web. Most of today's web applications demonstrate the characteristics of REST architectural style while building services on the Web.

While using REST, a client/server approach is used to separate user interface from data storage. The client/server interaction is stateless and the interactions use a uniform interface.

One of the key elements in the REST architecture is the concept of a resource. Servers host the resources and clients consume those resources. Any information that can be named can be a resource. According to this definition, a document, an image, and today's weather in New York are all examples of resources.

A resource has a resource identifier, a URI, associated with it. In other words, every piece of information has its own URI. This is also a key principle of the Semantic Web, which is an evolving extension of the World Wide Web in which the semantics of information and services on the Web are defined.

A resource can also have an associated representation, a document can be an HTML document, an image can be JPEG binary data and weather data can be represented using an XML document.

A given resource can also have an associated metadata such as media-type and last the modified time. Metadata is useful for consuming a resource. As an example, we can check the last modified time of weather data to see if we have any new updates on weather. We can fetch the resource based on control data that gives an idea on the novelty of the resource. If weather data has not been modified since the last time we fetched it, then there is no point in fetching a new copy of the same old data.

Earlier in the section, "HTTP and web services", we discussed the importance of HTTP as a transport protocol for web services. The simplicity and wide adoption in terms of almost all platforms supporting it has made HTTP the superior transportation of the Internet. REST architecture style can benefit from the elements of HTTP by applying REST concepts while implementing applications that run on the Web.

The extensibility and flexibility of the HTTP protocol has contributed a great deal to the success of the Web, and is considered the protocol of the Web today. HTTP protocol can be used to access resources, not only HTML pages, but all types of resources including images, videos, and applications.

When accessing resources with HTTP, a resource identifier is specified along with the action to be performed on that resource. URIs identify the resource. The action to be performed is defined using an HTTP verb. There is a set of HTTP verbs and each verb can have an associated semantics that helps to identify the action to be performed on the resource.

The following table summarizes the HTTP verbs and how they apply while using REST.

These HTTP verbs could be viewed in terms of how we can interact with a resource during the life cycle of a resource. PUT creates a resource, and starts the life cycle. GET retrieves the resource and HEAD query for the metadata. POST can be used to update the resource. Even though, in the context of using a web browser, a POST request could have an associated resource returned, in the context of REST, POST should ideally be used for the purpose of updating resources. GET, HEAD and POST can be used to make use of the resource during the lifetime of a resource. DELETE ends the life cycle of a resource. HTTP verbs help to provide a uniform interface for interacting with resources, which is a key principle of REST architectural style.

Let us consider an example. Say, there is a game of football. When a player comes to play, either at the start of the game or as a substitute, we can use PUT verb and create the player resource. This player can have a unique resource identifier, as an example http://football_game.example.org/game123/player_name. While the player keeps on playing, POST verb could be used to update the goals scored and the fouls committed by the player resource, and those who access the game information can use the GET operation to access the latest score and committed fouls details for that player resource. When the player gets substituted, DELETE operation could be used to end the player resource life cycle and a new player would replace him/her.

On the Web today, developers mostly use GET and POST, and rarely use PUT and DELETE. One of the key reasons for this situation is the restrictions applied by web servers on these methods. In addition, there are web server modules like the DAV module (http://www.webdav.org/mod_dav/) that provides an extension to the HTTP/1.1 protocol that allows clients to perform remote web content authoring operations. This means that in real world applications, developers tend to use POST for creation and deletion operations of resources, in addition to modifications. One of the excuses for not using PUT and DELETE is the fact that firewalls tend to block them. However, it would be good practice to use PUT and DELETE whenever possible rather than overloading POST to implement create and delete. By doing so, you can prevent accidental operations such as deletion of a resource while the user really wanted to update a resource with POST. This makes the API less ambiguous as well. http://www.php.net/manual/en/features.file-upload.put-method.php documents how to make use of the HTTP PUT method.

As we discussed earlier in this chapter, the advent of services has revolutionized the way web applications are developed and hence the way we use the Web. Out of the web applications we use today, a great majority of applications are written using PHP. Popular applications such as Flickr (http://www.flickr.com/), Wordpress (http://wordpress.com/) and many others are PHP based. According to the TIOBE programming community index [http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html], PHP is the fourth most used programming language and the most used scripting language. Given the wide adoption of PHP and the increasing awareness of REST, it is timely that we look into the ways in which we can do REST with PHP.

By combining the dynamic Web by PHP and mashups by REST and AJAX, we get a new breed of powerful web applications that would drive the future Web to new heights.

Rather than developing all application components in-house, and spending hours on debugging and fixing them, the web services allows us to use proven and tested applications as part of our own application. It is also noteworthy that the volume of data contained within web services and the services available today exposes an enormous volume of data for the taking by the web application developers. If we are building a social networking application and want to add a feature to share photos, we can use the Flickr API and add that functionality rather than writing our own photo sharing application. And the users would be happy because now they can share the photos they have already uploaded, rather than uploading them again, and maintaining the same images at multiple places.

Given the increasing number of services, and the drive towards the REST style architecture for services on the Web, PHP web application developers need to know how to consume REST services, how to build services themselves, and how to design their web applications so that they can reap maximum benefits from REST services for their applications.

There are many frameworks and tools in PHP that can help users build RESTful applications with ease. To consume services, that is to write clients for existing services, you can start with simple PHP API elements and implement clients. We already saw in some of the samples that were presented earlier in this chapter as to how this can be done.

$url = 'http://weather.yahooapis.com/forecastrss?p=USNY0996';
$xml = file_get_contents($url);

$client = curl_init($url);
curl_setopt($client, CURLOPT_RETURNTRANSFER, 1);
// POST XML data with our curl call
curl_setopt($client, CURLOPT_POST, 1);
curl_setopt($client, CURLOPT_POSTFIELDS, $xml_data);
$data = curl_exec($client);
curl_close($client);

This chapter introduced the concepts related to programmable Web, showed how HTTP and web services are related to each other, introduced the principles behind REST, explained how HTTP verbs are used in REST applications, explained the need for RESTFul web services while building PHP web applications, and introduced some frameworks and tools that can be used to work with REST in PHP.

REST is an architectural style with the concept of resource at its heart and with which we can build web services. REST principles can be applied with HTTP to build powerful services for the Web.

In this chapter, we also saw some bits and pieces of PHP code that can be used to access REST services that are publicly available. By now, you should have a general understanding of what REST is all about. In the next chapter, we will look into how PHP can be used to consume public REST style services in a bit more detail.