PHP Developer Blog - The blog of Andrei Gabreanu

• Tweet

• Tweet

Previously, we discussed about SOAP in CakePHP. We will now dive into the more exciting and interesting part of the web services: The REST. Keywords for REST? Simplicity, performance and scalability. But what is REST exactly?

1. What is REST?

The REST (representational state transfer) term was defined by Roy Fielding in his PhD dissertation to represent an architecture style of network systems. It is called this way because of the way the WWW(world wide web) works.
Let’s imagine we have a website page that we can access from: http://vehicles.com/normal-cars/model .
The representation of the requested resource is returned (e.g. bmw-3.html) and places the client in a state. The result of the client traversing the hyperlink in bmw-3.html is again, another resource and puts the client in a new state. This way, the client changes states every time its application changes (transfers from a state to another). Thus the name, Representational State Transfer.

2. Why REST and not SOAP ?

The major difference between SOAP and REST is that, unlike SOAP, REST does not have a standard (click to view SOAP standards). It is an architectural style. You cannot make a framework based on it, you can only understand and design your Web Services application based on those blue prints.

The major benefit of this is that you can keep everything simple and design your business logic however you want, not having any constrains. Lets put it like this: you can send to the REST server any format you want (xml, json etc) and get back an answer in the same way.

Unlike SOAP, you don’t have to do heavy coding just to get a simple system up & running, you don’t need to kill your bandwidth with useless xml documents (and the list can just go on) when you can just send / receive exactly what you need via REST.

3. REST standards

With this sub chapter, you may think I’m mad. You might say: “You just said there are no standards for REST!!” . Well there aren’t. But REST itself is based on some other standards. So, while there are no standards for REST itself, there are some for its dependencies. Here is the list of these:

• URL
• HTTP
• XML; HTML; JSON; GIF; JPEG and others (representations of resources)
• text/xml; text/html; image/gif; image/jpeg and others (MIME types)

4. Creating a very basic REST server and client

Here is a very very basic code snippet in php (you can adapt it to any major web programming language) that allows you to create a REST server and client:

Lets say we have a bookstore and we want to visitors to view book details both from our site or from theirs (using REST web services).
We would have something like this:

http://myCoolBookstoreWebsite.com/books/view/123.html for the plain html version

and

http://myCoolBookstoreWebsite.com/books/api-view/ for the web services method.

We will not talk about the first link (obvious reasons of course) but instead we will dive into the second one.

Basically, we will make a sever with the following contents:

$bookId = $_POST['bookId'];  //we will discuss this in the
//client example

$book = $this->getBookByID($bookId);

$book = json_code($book);

//send the book details to the client view and display it.
//He can then just get this content and decode it.

A more complex example would be, for example, to allow some users to add a new book to our database via REST web services. We can solve this problem by allowing the user to our ADD web service by adding an additional parameter to the request. This could something like api-key for example (Facebook anyone?).

We would then have:

$bookDetails = $_POST['bookDetails'];

$apiKey = $_POST['apiKey'];

if ( $this->checkIfApiKeyIsCorrect($apiKey)) {

//this function can do any sort of verification and
//it will return TRUE if the apiKey we sent is valid or not

$this->insertIntoDatabase($bookDetails);

}

Of course this example is very basic and is strictly for understanding the principles behind the REST servers. You should build far more complex systems (including heavy security measures) if you plan to use these type of systems in a production environment.

Now, lets talk about the client that will access our two examples:

$params = array('bookId' => 123);
$url = 'http://myCoolBookstoreWebsite.com/books/api-view/';

$ch = curl_init();
curl_setopt($ch, CURLOPT_POST, 1);
curl_setopt($ch, CURLOPT_POSTFIELDS, $params );
curl_setopt($ch, CURLOPT_URL,$url);
curl_setopt($ch, CURLOPT_RETURNTRANSFER,1);
$result= curl_exec ($ch);
$status = curl_getinfo($ch);
curl_close ($ch);
if ($status == '200') $result = json_decode($result);

Basically we will use CURL to send an array of parameters to our bookstore URL and get the response from it. We then check to see if the header status is 200 or not (200 means everything was ok). If so then decode the response with JSON (since we used this in our example) and we can do anything we want from this point on..

For the second example, absolutely nothing changes. We just add one more parameters that contains the apiKey we got from our bookstore webmaster, like this:

$params = array('bookId' => 123,'apiKey' => 'xxxxxxxxxx' );

For extra security you could expose your web services only via HTTPS so your transfer is secured by the protocol itself.

5. Conclusion

As you saw, you can build a web service server and client within minutes and still have the same performance and scalability as with SOAP. Even more, you can put effort into it and make a very complex system writing less code. The performance will be better, there will be less lines of code and you will have more time to learn more about this architectural system (or drink some beer with your friends).