This is part 2 of my rest service writing article. In
part 1 we saw the library which holds the functionality we will be using, and we also handled the incoming request and captured all the data we'll be using.
The REST Service
This is not really tricky but we're pulling together lots of ideas at this point. So we have already got the incoming request data, and we've intialised an object with that data. We have a reference to the object which contains all the functionality we want. And we need to work out which of the library functions we should call, and then transform that data into a good format to return to the user. Let's start with the handle() function:
public
function handle
() { $urlParts =
parse_url($this->
url);
// substring from 1 to avoid leading slash $this->_pathParts =
split('/',
substr($urlParts['path'],
1));
// glue the first part of the path to the upper case request method to make a unique function name, e.g. usersGET $method =
$this->_pathParts
[0] .
strtoupper($this->
method);
try
{ // now call the method in this class that wraps the one we actually want $this->
$method();
$this->
response->
output();
return true;
} catch
(Service_Exception_Abstract
$e) { $this->
response->
errorOutput($e);
} catch
(Exception
$e) { die('An Unexpected Error Has Occurred');
} return false;
}
The rest of this class contains the functions, such as userGET, which call the real worker functions from the library class we originally created. The functions in this section look something like this, and they throw exceptions if anything goes wrong - you can see these being caught in the handle() method posted above:
protected function userGET() {
$this->response->user = $this->library->getUserDetails($this->getVars['user_id']);
return true;
}
I also use a magic __call() method to return sensible error messages if a user tries to call something that doesn't exist (this was particularly helpful in development where not everything was there from the start!).
You can see here I'm using setting properties on the response object, but you could also just XML-ify and echo the output here if you wanted to. By using the response object however I am abstracting the XML transformation stuff and moving it to somewhere else so that it can be tested independently and even replaced as needed.
I'll write about the response class and how that works in the third installment.
This is part 3 of my article about writing a restful service server. If you haven't already, you might like to read part 1 (covering the core library and grabbing the information we need from the incoming request) and part 2 (covering the service handle
Tracked: Sep 05, 12:08