Had an episode recently where a client wanted to transfer some info to a third party. The third party uses MS technology, VBscript and ASP pages to host their sites. So we asked them if they have any sort of API that we could tap into for the client (An API stands for Application Program Interface. Basically, it's a way for outsiders to interact with a web program). They handed back an ASP page with some VBscript in it.
Hmmmm... we don't do MS stuff... including ASP. How are we going to transfer our data?
The answer? XML-RPC! We're familiar with XML as that's how we send thousands of property listings to various sources like TRULIA.COM, ZILLOW.COM, YAHOO.COM, GOOGLE.COM and others on a daily basis (and deep link them back to the client's site). We just never ran into a situation where we had to use XML to perform a single sign on (also known as an SSO or SSI) or interact with another program like this.
XML-RPC can take the info from us generated from a PHP file, transform it to XML, deliver the XML and have the receiving side read the XML, generated from an ASP file. Make sense? That's powerful!
It would look like this:
data -> php -> xml -> transfer xml -> receive xml -> xml -> asp -> data
XML-RPC has been around since the 1990's... That's more than 10 years ago! Since then, developers have discovered that it is lacking in details. So developers have enhanced XML-RPC with extra details (and structure) and re-branded it as SOAP.
SOAP is common and apparently the favored method for YAHOO web applications. The issue with SOAP is that it gives too much detail without easily identifyable structure. So we have no way of knowing what the data is unless we dissect it. This could take time and lots of it.
So a new though process sprung up. What if developers treated interaction just as they treat database interaction? Commonly referred to as CRUD (Create, Replace, Update, Delete). The result became what is known as REST or a RESTful API. A RESTful API gives each one of these processes a different link like so:
-www.whatever.com/api/create
-www.whatever.com/api/replace
-www.whatever.com/api/update
-www.whatever.com/api/delete
Good API's are going to have all of them. Flickr is an example of a well thought out API that offers exactly that: http://www.flickr.com/services/api/
We checked and the third party vendor didn't have either SOAP or REST, so we were stuck with XML-RPC.
The issue we came across was that info concerning XML-RPC is so fragmented and dated that it's hard to know what applies and what doesn't. There are classes and functions all over the place that people use. Do we use something trusted? Do we create our own (ugh)? Are the classes and functions out there still applicable in a PHP5 world?
The goal was simple. Generate an XML, send it, receive a response and display it (or print it or echo it) all with a single PHP5 file.
So without further ado, if you need to send an XML to an API and receive data back from it with PHP5:
//Sending xml line
$xml = "<?xml version=\"1.0\"?> \n \t <User Source=\"user_source_var\" Id=\"id_var\"></User>";
$url = "http://whatever.com/services/Login.asp";
$success = '<status>SUCCESS</status>';
$ch = curl_init(); // initialize curl handle
curl_setopt($ch, CURLOPT_URL, $url); // set url to post to
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1); // return into a variable
curl_setopt($ch, CURLOPT_TIMEOUT, 20); // times out after 20s
curl_setopt($ch, CURLOPT_POSTFIELDS, $xml); // add POST fields
$result = curl_exec($ch); //exec curl
//Create a SimpleXML element
$xml = new SimpleXMLElement($result);
//check return from server
//if return contains success redirect to login
if ($pos = strpos($result, $success)) {
list($junk, $id) = split("id={", $result, 2);
list($id, $junk) = split("}", $id, 2);
//This print the whole raw xml:
//echo $result . "<br />";
//This prints the xml as an object:
//print_r($xml);
//This gets the a node & prints it:
$message = (string)$xml->parent_node->child_node;
print_r($message);
} else {
//if error - fail to screen
echo "failed";
}
?>
This info is offered from a personal perspective and offered to help people understand how we think and view situations. We in no way think that we are authoritative on this subject (or any other for that matter!).